public inbox for archer@sourceware.org
 help / color / mirror / Atom feed
From: Gary Benson <gbenson@redhat.com>
To: archer@sourceware.org
Cc: Paul Pluzhnikov <ppluzhnikov@google.com>
Subject: Re: Improved linker-debugger interface
Date: Tue, 31 May 2011 16:25:00 -0000	[thread overview]
Message-ID: <20110531162428.GB3464@redhat.com> (raw)
In-Reply-To: <BANLkTimn8XXk3nf86zh4ELtV_-FDYugsuQ@mail.gmail.com>

Paul Pluzhnikov wrote:
> On Wed, May 25, 2011 at 8:36 AM, Gary Benson <gbenson@redhat.com> wrote:
> > The solution I'm proposing is this:
> 
> It's great that you are working on this, thanks!

No problem!

> 1. Stripped binaries.
> 
>    There is a DT_DEBUG entry pointing to _dl_debug_state (set by
>    ld-linux)
> 
>    You might want to have a new dynamic tag, pointing to
>    _dl_debug_state_extended(), so the debugger would be able
>    to track shared libs using the new mechanism even when
>    everything is stripped.

Like Tom said, I'm using SystemTap probes within the function rather
than looking up the symbol.  Having more than one probe in there
allows gdb to be more selective about when it stops (and therefore
stop less often).

Is it possible for in-process debuggers to locate SystemTap probes?
Forgive me if this is an obvious question but I'm new to this :)

> 2. In-process debuggers.
> 
>    There are many use cases for "self-aware" binaries. For example,
>    google-perftools collects profiling info with stack traces, and
>    getting a stack trace requires that you know which DSOs are
>    loaded into the process.
> 
>    The current interface is very hostile to such debuggers, as
>    _dl_debug_state
> 
>    A) is called directly by libc (so there is no way to interpose
>    it), and
>    B) compiles down to a single 'ret', so there is no way to place
>    a patch on top of it.
> 
>    This leads to all kinds of suboptimal solutions (such as scanning
>    /proc/self/maps; which doesn't work if /proc is not mounted).
> 
>    A patch to make _dl_debug_state indirect through r_debug.r_brk
>    has been rejected:
>    https://bugzilla.redhat.com/show_bug.cgi?id=70407
> 
>    Perhaps co-operation with "in-process" debuggers would be more
>    acceptable for a new interface?

Is making _dl_debug_state_extended an indirect call the only non-hacky
way to allow in-process debuggers to get these notifications, or are
there other possibilities?

By the way, although _dl_debug_state compiles to a single ret, I think
function entries are aligned so you might get a few more bytes to work
with on some platforms.  Obviously this doesn't negate the need for a
proper interface, but I noticed it earlier and wondered if it might
help you.

Also by the way, glibc has what it calls "auditing checkpoints" in
various places, I don't know if these are something you can use?

Thanks,
Gary

-- 
http://gbenson.net/

  parent reply	other threads:[~2011-05-31 16:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-05-25 15:37 Gary Benson
2011-05-25 18:21 ` Tom Tromey
2011-05-26 17:02   ` Gary Benson
2011-05-26 17:25     ` Tom Tromey
2011-05-26 17:37 ` Paul Pluzhnikov
2011-05-26 17:47   ` Tom Tromey
2011-05-26 21:07     ` Tom Tromey
2011-05-31 16:25   ` Gary Benson [this message]
2011-05-31 19:46     ` Tom Tromey
2011-05-31 20:41       ` Paul Pluzhnikov
2011-05-31 20:46         ` Tom Tromey
2011-05-31 21:05           ` Paul Pluzhnikov
2011-06-02 23:56             ` Tom Tromey
2011-06-07 16:58 ` Jan Kratochvil
2011-06-08 10:56   ` Gary Benson
2011-06-01  1:24 Frank Ch. Eigler
2011-06-02 23:56 ` Tom Tromey

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=20110531162428.GB3464@redhat.com \
    --to=gbenson@redhat.com \
    --cc=archer@sourceware.org \
    --cc=ppluzhnikov@google.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).