This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
- To: ac131313 at cygnus dot com
- Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release
- From: Mark Kettenis <kettenis at wins dot uva dot nl>
- Date: Mon, 7 Feb 2000 17:26:59 +0100 (MET)
- CC: gdb at sourceware dot cygnus dot com
- References: <389ECBAF.66013B07@cygnus.com>
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