From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24229 invoked by alias); 11 Oct 2004 17:55:30 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24205 invoked from network); 11 Oct 2004 17:55:28 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 11 Oct 2004 17:55:28 -0000 Received: from drow by nevyn.them.org with local (Exim 4.34 #1 (Debian)) id 1CH4OL-0003hW-1O; Mon, 11 Oct 2004 13:55:25 -0400 Date: Mon, 11 Oct 2004 19:14:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: Randolph Chung , gdb@sources.redhat.com Subject: Re: Question about _dl_debug_state and new glibc Message-ID: <20041011175524.GA29450@nevyn.them.org> Mail-Followup-To: Kevin Buettner , Randolph Chung , gdb@sources.redhat.com References: <20041011172207.GA14151@tausq.org> <20041011104647.6a03d9ce@saguaro> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041011104647.6a03d9ce@saguaro> User-Agent: Mutt/1.5.5.1+cvs20040105i X-SW-Source: 2004-10/txt/msg00285.txt.bz2 On Mon, Oct 11, 2004 at 10:46:47AM -0700, Kevin Buettner wrote: > On Mon, 11 Oct 2004 10:22:07 -0700 > Randolph Chung wrote: > > > I've been away from gdb for a bit, so hopefully this is not something > > simple I missed while I've been away :) > > > > It appears that newer versions of glibc now marks the _dl_debug_state > > function as hidden, making it not visible to gdb. This breaks the > > solib tracking code in solib-svr4.c..... > > > > Looking at the docs, it looks like the "proper" way for gdb to do this > > is to look up the r_debug symbol and use the r_brk member to locate > > _dl_debug_state's address. is there any particular reason why we don't > > do this in gdb? Only for static executables usually; for dynamic executables it's supposed to be DT_DEBUG if that's available. Same difference. > I can't think of any reason. I'm guessing that it was more expedient > for the original authors of the code to do it the way it was done. > In any case, I know of no reason not to change it so that it's done > "properly". We set the breakpoint on _dl_debug_state before starting the inferior. _dl_debug_initialize initializes _r_debug somewhat later... I'm not sure how it is supposed to be used. Do either of you know? I see it hasn't been exported since March. Blech. -- Daniel Jacobowitz