From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22636 invoked by alias); 26 Sep 2004 18:38:04 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22627 invoked from network); 26 Sep 2004 18:38:03 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 26 Sep 2004 18:38:03 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id i8QIbx1d031977; Sun, 26 Sep 2004 20:37:59 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id i8QIbxAH001265; Sun, 26 Sep 2004 20:37:59 +0200 (CEST) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id i8QIbuxo001262; Sun, 26 Sep 2004 20:37:56 +0200 (CEST) Date: Sun, 26 Sep 2004 18:38:00 -0000 Message-Id: <200409261837.i8QIbuxo001262@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: cagney@gnu.org, gdb-patches@sources.redhat.com In-reply-to: <01c4a31e$Blat.v2.2.2$91a0d700@zahav.net.il> (eliz@gnu.org) Subject: Re: [RFC] Suggested ways to remove the need for xm-go32.h References: <01c49d82$Blat.v2.2.2$23875ec0@zahav.net.il> <20040923050534.GA11936@trixie.casa.cgf.cx> <41526D73.nailWK21NVX4@mindspring.com> <20040923151802.GC968@gnat.com> <20040923175721.GA30999@nevyn.them.org> <4154372C.7080100@gnu.org> <01c4a31e$Blat.v2.2.2$91a0d700@zahav.net.il> X-SW-Source: 2004-09/txt/msg00436.txt.bz2 Date: Sat, 25 Sep 2004 18:40:53 +0200 From: "Eli Zaretskii" > Date: Fri, 24 Sep 2004 11:03:08 -0400 > From: Andrew Cagney > Cc: Michael Chastain , me@cgf.cx, > gdb-patches@sources.redhat.com > > We've no evidence that we've a real problem here, and hence no evidence > that a wrapper is needed. All I see a dig achieving is to flush out > legacy systems on which GDB no longer builds. If someone with such a > legacy system really really needs a modern GDB then I'm sure that > they'll step up to the challenge of solving this and many other problem. Mark, how do you feel about losing the wrappers? Would it be okay for me to do it that way, or do you feel strongly about them? I don't feel too strongly about it. The "b" modifier is mentioned in the 4.3BSD/Net2 headers, and Ultrix 4.0 also has it. That's pretty ancient stuff. But I'd appreciate it if you, and other people, keep in the back of your mind that there may still be systems that don't support the "b" modifier. So avoid using "b" wherever possible, and keep using the macro's from include/fopen-*.h. In the discussion we've had over the past days people have been taling about supported and unsupported hosts, as if there is some restricted list of machines that GDB runs on. While that's currently the case, I think it's wrong to think about it like that. Yes, we have a list of supported *native* hosts, but actually it should be possible to compile GDB on any system that's POSIX-ish. If that system isn't on the list of native host, you wouldn't get the ability to debug native programs, but you'd still be able to use the remote protocol to debug programs on another system. Therefore we should try to make the generic parts of GDB as portable as we can. IMHO, compiling GDB on ancient systems helps to keep us honest about that. That's why I recently added back the vax-dec-ultrix4* stuff. Cheers, Mark