From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: hjl@lucon.org Cc: kingdon@redhat.com, gdb@sourceware.cygnus.com Subject: Re: Shared libraries on Linux Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002110749.e1B7nkw00408@delius.kettenis.local> References: <200002082201.RAA18487@devserv.devel.redhat.com> <20000208182138.A17050@lucon.org> <200002100439.XAA32612@devserv.devel.redhat.com> <20000210162640.A24492@lucon.org> X-SW-Source: 2000-q1/msg00220.html Date: Thu, 10 Feb 2000 16:26:40 -0800 From: "H . J . Lu" On Wed, Feb 09, 2000 at 11:39:49PM -0500, Jim Kingdon wrote: > > Tue Feb 8 18:19:22 2000 H.J. Lu > > Well, this one does work for me. > > Based on reading the code (I didn't actually step through it), it > looks to me like the way it works is in the relevant case it calls > clear_solib, dumps all symbols, and then reloads them (even for > libraries which are still loaded). That seems slow so I wonder why > the code was written that way. I believe there are 2 problems Sam tried to fix: 1. Restart the problem when you have breakpointers set in a DSO which can be a shared library or loded in via dlopen. 2. You have DSOs loaded/unloced via dlopen/dlclose. "info shared" may be wrong. And again, I ask you for proof of 1. As far as my experience goes, restarting after setting a breakpoint in a shared object works flawlessly. Sam's patch may not be the best. But it addresses those 2 problems. If there are no better alternatives, I don't see why we cannot use it even if it is slow. I don't know if anybody uses remote debugging with systems that use solib.c, but that could become really painful if it's done over a slow link. Otherwise, we might want to add the patch to the release branch once that's been created, but I think a FIXME should be added. Also people should expect some regressions at the moment we really try to fix things. This "solution" has the potential of hiding bugs that might be uncovered if a more intelligent solution is found. Mark