Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: "André Pönitz" <apoenitz@trolltech.com>
To: gdb@sources.redhat.com
Subject: How to use  auto-solib-add  properly?
Date: Tue, 07 Oct 2008 10:27:00 -0000	[thread overview]
Message-ID: <200810071228.21179.apoenitz@trolltech.com> (raw)


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'


             reply	other threads:[~2008-10-07 10:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-07 10:27 André Pönitz [this message]
2008-10-07 14:02 ` Daniel Jacobowitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200810071228.21179.apoenitz@trolltech.com \
    --to=apoenitz@trolltech.com \
    --cc=gdb@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox