How to use auto-solib-add properly?

How to use auto-solib-add properly?

[André Pönitz]

Hi all.

I am trying to find a way to make existing incarnations of gdb start up 
reasonably quick in the presence of shared objects with large amounts
of debug information. 

The test application in question is linked to about 50 shared objects
and loads a couple of plugins pulling in another 50 shared objects.
Total debug information read is a bit less than 1 GB, most of it is in 
"external" "foo.so.debug" files. Application starts in about 3 seconds
outside gdb (with "cold" caches), within gdb it takes about 2 minutes and
uses about 1.4 GB of RAM.

I want to be able to set break points by file and line and/or function
name in both the main application and in dlopen'd files.

My idea was to use

  set auto-solib-add off
  set stop-on-solib-events 1

and whenever a "shared library event" is encountered I'd do:

  for all shared objects except some big ones that I want to avoid do:
     sharedlibrary <lib>
  continue

Am I on the right track here? Are there easier ways to achieve what I want?
Is there a way to find out what exactly triggered the shared lib event?
In MI one usually gets a 'reason' field when hitting a break point. For shared
lib events the output is pretty short, though:

  ~"Stopped due to shared library event\n"
  17*stopped,thread-id="0"
  (gdb)


Thanks for any advice in advance,
Andre'

Re: How to use auto-solib-add properly?

[Daniel Jacobowitz]

On Tue, Oct 07, 2008 at 12:28:13PM +0200, Andr? P?nitz wrote:
> My idea was to use
> 
>   set auto-solib-add off
>   set stop-on-solib-events 1
> 
> and whenever a "shared library event" is encountered I'd do:
> 
>   for all shared objects except some big ones that I want to avoid do:
>      sharedlibrary <lib>
>   continue

Sonds like it might work.

> Is there a way to find out what exactly triggered the shared lib event?

Not in any existing version of GDB, though this is on my wishlist.

-- 
Daniel Jacobowitz
CodeSourcery