Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Per Bothner <per@bothner.com>
To: tromey@redhat.com
Cc: Gdb List <gdb@sources.redhat.com>
Subject: Re: breakpoints in shared libraries
Date: Tue, 13 Nov 2001 10:20:00 -0000	[thread overview]
Message-ID: <3C01584A.2000609@bothner.com> (raw)
In-Reply-To: <87elmmaeki.fsf@creche.redhat.com>

Tom Tromey wrote:

>Suppose I set a breakpoint in a shared library.  I find on my Linux
>box I can only do this after the inferior has been started.  So I use
>`b main', then `run', then set the breakpoints I really care about.
>(This gets old fast, btw.)
>
Yes. It should be fixed.  I seem to remember that at one point Gilmore
wrote code so that gdb could set a break point on a shared Solaris library
that had not been loaded.  There really is no excuse for gdb not being able
to set a breakpoint on a shared library specified on the linker command
line.  (Shared libraries loaded with an explicit call to dlopen are of
course a different matter.)

It should not be very difficult, but it requires knowing how the linker
does things.  Somewhere in the executable there has to be a data structure
that lists the libraries that will be loaded.  I seem to remember there 
actually
is some Linux program that will list the shared libraries requried by an
excutable, which should make it easy..  Gdb just has to be able to read
that data structure, and pre-load the symbol tables for the shared 
libraries.
You can then set breakpoints in those shared libraries.  When the library
actually gets loaded, we don't need to read the symbol tables, but we
need to relocate them.

Let's fix the real bug instead of kludge to make the bug slightly less
obnoxious.

    --Per




  parent reply	other threads:[~2001-11-25 20:44 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-13  9:05 Tom Tromey
2001-11-13  9:41 ` Daniel Jacobowitz
2001-11-13 10:11   ` Tom Tromey
2001-11-13 10:20 ` Per Bothner [this message]
2006-02-14 16:29 Florian Hackenberger
2006-02-14 17:00 ` Daniel Jacobowitz
2006-02-14 17:10   ` Florian Hackenberger
2006-02-14 17:13     ` Daniel Jacobowitz
2006-02-14 17:52       ` Paul Koning
2006-02-14 18:00         ` Florian Hackenberger
2006-02-14 17:21   ` Mark Kettenis
2006-02-14 17:23     ` Bob Rossi
2006-02-14 17:31     ` Daniel Jacobowitz
2006-02-14 17:47       ` Mark Kettenis
2006-02-14 17:08 ` Mark Kettenis
2006-02-14 17:20   ` Florian Hackenberger

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=3C01584A.2000609@bothner.com \
    --to=per@bothner.com \
    --cc=gdb@sources.redhat.com \
    --cc=tromey@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