This is the mail archive of the gdb@sourceware.cygnus.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]

Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release


   From: Andrew Cagney <ac131313@cygnus.com>
   Date: Tue, 08 Feb 2000 00:26:45 +1100

   [Please follow up to the general GDB mailing list]

   Hello,

   Given it is now almost a year since the last release of GDB (4.18) and
   given also the number of significant internal changes made since that
   release (event-loop, multi-arch, ui-out, ISO-C, obsolete code, ...), it
   is now time to start anew the process of releasing a major version of
   GDB - GDB 5.0.

   As this release is being conducted entirely from the (new!) public CVS
   repository I'm hoping that a more aggressive release schedule can be
   achieved.  With that in mind, I've tentatively planned: two weeks of
   patch resolution; the cutting of the 5.0 branch (2000-02-21?); one week
   of last minute checks; and then the 5.0 release (29/2 2000-02-29?).
   (Everyone is free to roll on the floor laughing at this point :-)

I think I'll take that liberty :-)

   It would be good to see this GDB release running on *Linux, *BSD and
   cygwin as well as plenty of the more traditional UNIX platforms.

Speaking as the maintainer of "hurd native": I have some small patches
lying around that could be integrated in a week or so.

Speaking as a user and occasional hacker on "x86 linux native": There
are still a lot of issues to be resolved.

* GDB doesn't work on Linux 2.0 right now.  Tom Tromey has submitted a
  patch to fix this.

* GDB doesn't compile on the upcoming glibc 2.1.3.  I've submitted a
  patch to fix things.  However, it looks as if the new libthread_db
  based threads debugging code is not completely in sync with the
  upcoming glibc 2.1.3.  I don't know if Michael Snyder is still
  working on this, so I didn't really look into it yet, but
  compilation isn't possible with glibc 2.1.3.  After a quick fix
  (which my patch does not include) I still get a lot of warnings.
  Since this is new code I think the number of warnings should be
  reduced to the absolute minimum.

* Support for long double on the i386.  The current code-base contains
  some hacks that make it more or less possible to print long doubles
  on some platforms (linux native, djgpp native).  But these
  implementations are not very well thought out and use a lot of
  (unecessary) target specific hooks.  There has been a discussion
  about a better approach back in November, but it died without
  reaching a real discussion :-(.  Getting this right is not critical,
  but releasing GDB with those unwanted hooks might give out the wrong
  message.

* Recognition of signal trampolines, the current code doesn't work on
  Linux 2.2 and doesn't work on glibc 2.  I've submitted a patch, but
  unfortunately this uncovers another bug: stepping out of signal
  trampolines is broken.  It is probably not really critical to get
  this right in GDB 5.0.

* Support for unloading of shared libraries.  The current code-base
  doesn't really support this.  HJ Lu forwarded some patches that hack
  around this, but I don't think they are acceptable.  They introduce
  two more (uneccessary) hooks.  Personally I don't fixing this for
  GDB 5.0 terribly important.  There isn't that many code out there, that
  explicitly unloads shared libs.

I think having an "x86 linux native" port with working threads support
in GDB 5.0 is very important.  Right now, a lot of people still use HJ
Lu's GDB 4.17 based version.  GDB 4.18 didn't really work on Linux
(especially for threaded apps), and most people who complained on
other places than bug-gdb, were told to use HJ's version instead.  The
result is that GDB 4.18 didn't get a lot of testing on Linux, and that
a lot of bug reports and fixes do not reach us.

Another problem is that the official maintainer of "x86 linux native"
seems to be very busy lately.  I don't blame Jim for "having a life"
(or whatever he might be doing in his spare time), but we should try
to speed up Linux/i386 and general i386 development, or otherwise we
don't stand a chance to come even near your suggested release date.

Mark

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