Re: Shared libraries on Linux

[Jim Kingdon <kingdon@redhat.com>]

> Tue Feb  8 18:19:22 2000  H.J. Lu  <hjl@gnu.org>

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 <ac131313@cygnus.com>
To: GDB Patches <gdb-patches@sourceware.cygnus.com>
Cc: GDB Discussion <gdb@sourceware.cygnus.com>
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" <dan@cgsoftware.com>
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 <dan@cgsoftware.com>
To: Mark Kettenis <kettenis@wins.uva.nl>
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: <Pine.LNX.4.10.10002071657110.9999-100000@propylaea.anduin.com>
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
> 
>