This is the mail archive of the archer@sourceware.org mailing list for the Archer 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]

Re: Improved linker-debugger interface


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/


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