From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Kingdon To: hjl@lucon.org Cc: gdb@sourceware.cygnus.com Subject: Re: Shared libraries on Linux Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002100439.XAA32612@devserv.devel.redhat.com> References: <200002082201.RAA18487@devserv.devel.redhat.com> <20000208182138.A17050@lucon.org> X-SW-Source: 2000-q1/msg00196.html > 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. >From ac131313@cygnus.com Sat Apr 01 00:00:00 2000 From: Andrew Cagney To: GDB Patches Cc: GDB Discussion Subject: [Maint] Second testsuite maintainer Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <38D84B37.B90E15AB@cygnus.com> X-SW-Source: 2000-q1/msg00767.html Content-length: 282 Another addition: Add Fernando to list of testsuite maintainers. testsuite Stan Shebs shebs@apple.com Fernando Nasser fnasser@cygnus.com hp tests (gdb.hp) *Jimmy Guo adl-debugger-wdb-merge-guru@cup.hp.com Java tests (gdb.java) Anthony Green green@cygnus.com Andrew >From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: "Daniel Berlin" To: shebs@shebs.cnchost.com Cc: dan@cgsoftware.com, muller@cerbere.u-strasbg.fr, gdb@sourceware.cygnus.com Subject: Re: Status of submitted patches? Pascal language addition patch. Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-id: <200002021720.JAA19067@propylaea.anduin.com> X-SW-Source: 2000-q1/msg00096.html Content-length: 1603 > >Daniel Berlin wrote: >> >> > Apart from a few comments just after my email, I never got any >> >constructive answer about the patch itself. >> I must say, this isn't the first time this has happened. >> I think we have no official maintainer. > >The list in gdb/MAINTAINERS lists specific areas of responsibility. >For new things that don't fall in an existing area, I would either >evaluate things myself or assign to the closest plausible person - >which in this case is David Taylor, who's already responded. I was reading through the website. Never thought to actually look at that file. Doh. > > >That would be great. In general, because an incautious checkin can >cause huge amounts of chaos, it's better to take charge of a limited >area and see how that goes. I know that in the past we've talked about >you taking over C++ support, and that still seems to me like a good >starting point. Works for me. > >> If we have a maintainer, no offense, but um, considering i haven't seen >> any comments on any patches on gdb-patches in a while, and no sign of >> them being integrated, you need to get on the ball. > >I agree. To make excuses, maintenance is in an awkward situation right >now, what with my life in major transition, Cygnus maintainers probably >preoccupied with the Red Hat merger, and the GDB steering committee >still unformed. This should be sorted out in a couple of weeks though. Oh, i understand all of this, I just see people who submit patches starting to get annoyed at the lack of response, and wanted to offer my help in any way possible. > >Stan >From dan@cgsoftware.com Sat Apr 01 00:00:00 2000 From: Daniel Berlin To: Mark Kettenis Cc: hjl@lucon.org, 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: References: <200002080051.e180pit26400@delius.kettenis.local> X-SW-Source: 2000-q1/msg00144.html Content-length: 731 > > I bet debugging apps that dlopen() a shared object, then dlclose() it > and then dlopen() a different shared object won't work under BeOS > either (if that is possible under BeOS at all), but other than that, > I'm not aware of any deficiencies. No, they work fine. You don't dlopen, you use load_add_on and unload_add_on, but it's basically they same thing (you can emulate dlopen/dlclose perfectly with it). I just get notification of image (executable/shared library/etc) createion/deletion from the debugger nub, and handle it there. > > HJ, are you really aware of problems with debugging shared objects > that don't involve a dlclose() somehow? If you are, could you *please* > provide a testcase. > > Mark > >