Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Kevin" == Kevin Buettner <kevinb@cygnus.com> writes:
Kevin> Okay.  However, just so that we have some patches to look at while
Kevin> we conduct our deliberations, I've appended a patch below which
Kevin> shows what the reversion patch would look like.

Thanks.  At the very least, that make sure we're all on the same page.

>> I'm pretty ambivilent about it myself.  In my experience, beyond toy
>> programs, stubs get hacked quite extensively to integrate them into
>> the target system.  Removing protototypes would be the least of the
>> user's worries.

Kevin> I see.  I knew that the stubs were examples, but I was also
Kevin> under the impression that the examples that we include would
Kevin> (or did at one time) compile on some real system.

I'm pretty sure the stubs build and are usable as is.  I recently
built i386-stub.c for some tests.  

What I was trying to say is that when a stub is integrated into a
system, it may be modified to fit the conventions already being used.
For example, if a system has a constant exception handler, the stubs
code that installs exception vectors is probably going to be ripped
out and the appropriate entries in the table will be made to point to
the stub.  If the target system's exception stack frame saves
registers in a different order, the stub may be modified to
fetch/store registers in the target's order instead of imposing the
GDB order on the target, etc.  There are a lot of implementation
details that might necessitate hacking the stub.

        --jtc

-- 
J.T. Conklin
RedBack Networks