[commit] Deprecate remaining STREQ uses
Andrew Cagney
cagney@gnu.org
Wed Dec 31 19:48:00 GMT 2003
>> Date: Mon, 15 Dec 2003 10:51:11 -0500
>> From: Daniel Jacobowitz <drow@mvista.com>
>>
>> By the way, is there any reason DJGPP couldn't be tested in Bochs,
>> qemu, vmware, plex86, or some other new system emulator I haven't heard
>> of yet?
>
>
> I don't know about these emulators. In general, if they can run
> DOS/Windows code and still support async subprocesses to the degree
> that `expect' runs, then yes.
I don't think it is worth the effort. I think djgpp using dejagnu's
remote host code would be a bigger return but even then I'm backing away
from the idea :-)
Michael, look at djgpp this way:
- i386 architecture
very well tested and (currently at least) where all the bugs are
- i386 @&^$(*^@#$*& coff
not so well tested :-( we (as a group) need to find a way of testing
this as a cross platform :-/ I think it is were the future bugs will
be. Would testing a *-*-pe platform help with this (arm comes to mind)?
- djgpp nat code
not so well tested, but hardly matters. break main/run should tell us
that that part of the code is still live.
So of the above, only the coff symbol reader is a real risk.
As for eliminating code, we're about done with architectures. target
vectors and natives will (and should be) next in the hot seat, but
there, at least for a first pass flushing anything obviously dead (as I
did to MIPS recently) will get us well along the path.
Also note that we can never draw a simple straight line here. DJGPP,
for instance, is, or at least was, considered an important system so
some rule bending (which often translates into me doing the work no one
else is willing to) is in order.
enjoy,
Andrew
More information about the Gdb
mailing list