This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] Suggested ways to remove the need for xm-go32.h


   Date: Sat, 25 Sep 2004 18:40:53 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Fri, 24 Sep 2004 11:03:08 -0400
   > From: Andrew Cagney <cagney@gnu.org>
   > Cc: Michael Chastain <mec.gnu@mindspring.com>, 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]