From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: kingdon@redhat.com Cc: gdb@sourceware.cygnus.com Subject: Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002072132.WAA08489@soliton.wins.uva.nl> References: <389ECBAF.66013B07@cygnus.com> <200002071626.RAA18391@landau.wins.uva.nl> X-SW-Source: 2000-q1/msg00135.html From: Jim Kingdon 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