This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
How to use auto-solib-add properly?
- From: André Pönitz <apoenitz at trolltech dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 7 Oct 2008 12:28:13 +0200
- Subject: 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'