This is the mail archive of the
mailing list for the Archer project.
Re: Improved linker-debugger interface
- From: Paul Pluzhnikov <ppluzhnikov at google dot com>
- To: archer at sourceware dot org
- Date: Thu, 26 May 2011 10:36:42 -0700
- Subject: Re: Improved linker-debugger interface
- References: <20110525153649.GB3149@redhat.com>
On Wed, May 25, 2011 at 8:36 AM, Gary Benson <firstname.lastname@example.org> wrote:
> The solution I'm proposing is this:
It's great that you are working on this, thanks!
You might wish to consider the following points, which (AFAICT) you are
not currently addressing.
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.
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
The current interface is very hostile to such debuggers, as
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
Perhaps co-operation with "in-process" debuggers would be more acceptable
for a new interface?