Re: [commit] Deprecate remaining STREQ uses

[Andrew Cagney <cagney@gnu.org>]

>> 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