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


Gary,

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!

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
   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?


Thanks,
-- 
Paul Pluzhnikov


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