This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
>>>>> "Stan" == Stan Shebs <shebs@apple.com> writes:
Stan> So can you imagine any possible circumstance in which having a
Stan> prototyped and/or ISO stub would be a problem for an actual
Stan> embedded system developer today? The only example I can
Stan> synthesize involves somebody that can only use GDB with one of
Stan> Sun's old compilers adapted for embedded use, but not GCC.
Stan> That's pretty farfetched though, and I've never heard of an
Stan> actual case like that.
I have :-(.
When I went to Cisco, the project I worked on had once used BSD/OS's
native toolchain to generate the image for the target system. Then
they switched to Plan 9 and used the Plan 9 native tools to generate
the image. While both BSD/OS (gnu-based) toolchain and the Plan 9
tools understood prototypes; I mention this just to confirm that there
are folks out there that do *really wierd things*.
I have to agree, it's hard to imagine a situation where a prototyped
stub would be problem. As I mentioned in earlier messages, even if a
developer worked in an environment without prototypes, fixing that is
nothing compared to integrating it into his/her target system.
--jtc
--
J.T. Conklin
RedBack Networks
- References:
- [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
- Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
- Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
- Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c
- Re: [PATCH RFC] Protoize m32r-stub.c, m88k-nat.c, m88k-tdep.c