From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12705 invoked by alias); 26 May 2011 17:37:32 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 12681 invoked by uid 22791); 26 May 2011 17:37:31 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org MIME-Version: 1.0 In-Reply-To: <20110525153649.GB3149@redhat.com> References: <20110525153649.GB3149@redhat.com> From: Paul Pluzhnikov Date: Thu, 26 May 2011 17:37:00 -0000 Message-ID: Subject: Re: Improved linker-debugger interface To: archer@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-SW-Source: 2011-q2/txt/msg00004.txt.bz2 Gary, 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 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