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

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Jim Kingdon <kingdon@redhat.com>
   Date: 07 Feb 2000 09:08:51 -0800

   > * 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.

   As far as I know there is more out there than you might realize.  A
   modern application like mozilla uses dlopen() a lot (feel free to
   flame about whether this tendency is a fad or really useful but that
   isn't the point).  For example see
   http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=5130

Well, if there indeed is a considerable amount of code out there that
dlcloses its libraries and people are using GDB to debug it, then we
should raise the priority of fixing this a bit.

   I'm hoping to find time to look at this.  Whether or not it is me, I
   hope that we can get some victims ^W contributors working on finding a
   solution rather than merely talking about what was wrong with the
   patch which was sent to this list.

Well, I have looked into this issue (and the more I look into it the
more I'm convinced that the patch is just a quick hack, and a bad one
at that) and I think that we simply have to implement unloading of
shared objects in add_solib, looking at the dynamic linker state and
such.  I havent figured out yet how this would interact with
core-dumps and attach/detach.  There is also the problem that solib.c
is a bit of a maintenance nightmare since it contains some nasty code
to support both SunOS 4 a.out and SVR4 ELF (SunOS 5) shared objects in
one file.  So I decided to work on totally splitting out the code for
ELF shared libs from solib.c.  But that isn't going to lead to very
quick results...

   But I wouldn't ask that this hold up GDB 2000.  It could be a somewhat
   involved process to get a good solution.  IMHO, a release is the time
   to stabilize what is already there, rather than to start hacking away
   to add new stuff.

...and would potentially destabilize things.

   > I think having an "x86 linux native" port with working threads support
   > in GDB 5.0 is very important.

   Have you tried GDB from CVS in the last 6 months or so?  I'm not aware
   of any known bugs and Red Hat Linux has been shipping with the code
   which is in CVS for a while (I can offer details if needed).

The current CVS version in combination with glibc from CVS fails the
thread support tests in the testsuite massively.  I did not have the
time to look into this though.

   > Another problem is that the official maintainer of "x86 linux
   > native" seems to be very busy lately.  I don't blame Jim [Blandy]
   > for "having a life"

   Well, I'm likely to get/stay involved since I just told the Red Hat
   Linux people that I'd continue to build the packages for GDB.  If you
   think maintainer bandwidth is what is holding up things like the long
   double one, feel free to see if there is anything I can do to help
   (although I'm not official the way JimB is, at least not yet).

I'd certainly like to put some of my time into improving i386 support
in GDB, especially since most of this work means improving GDB on the
Hurd too.  And I hope that the patches I sent in the last few months
"prove" this commitment.  A speedup in evaluation and/or integration
of patches would certainly be welcome.  There have been suggestions
like "write-after-approval" access for more people.  Anyway, I'm sure
things will be worked out in the end.

Mark