This is the mail archive of the 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


On Wed, May 25, 2011 at 8:36 AM, Gary Benson <> 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
   been rejected:

   Perhaps co-operation with "in-process" debuggers would be more acceptable
   for a new interface?

Paul Pluzhnikov

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