From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23649 invoked by alias); 31 Dec 2003 19:48:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 23642 invoked from network); 31 Dec 2003 19:48:32 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 31 Dec 2003 19:48:32 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 06D4F2B8F; Wed, 31 Dec 2003 14:48:31 -0500 (EST) Message-ID: <3FF3280E.2010407@gnu.org> Date: Wed, 31 Dec 2003 19:48:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 MIME-Version: 1.0 To: Eli Zaretskii Cc: Daniel Jacobowitz , mec.gnu@mindspring.com, gdb@sources.redhat.com Subject: Re: [commit] Deprecate remaining STREQ uses References: <20031215062230.CD6E94B412@berman.michael-chastain.com> <20031215155111.GA13947@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-12/txt/msg00308.txt.bz2 >> Date: Mon, 15 Dec 2003 10:51:11 -0500 >> From: Daniel Jacobowitz >> >> 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