This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

How to use auto-solib-add properly?


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'


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]