From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28237 invoked by alias); 9 Feb 2006 13:51:49 -0000 Received: (qmail 28228 invoked by uid 22791); 9 Feb 2006 13:51:48 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 09 Feb 2006 13:51:47 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1F7CD2-00065Q-2A; Thu, 09 Feb 2006 08:51:44 -0500 Date: Thu, 09 Feb 2006 13:51:00 -0000 From: Daniel Jacobowitz To: Jim Blandy Cc: Patrick Alken , gdb@sourceware.org Subject: Re: gdb and shared libraries Message-ID: <20060209135144.GA23355@nevyn.them.org> Mail-Followup-To: Jim Blandy , Patrick Alken , gdb@sourceware.org References: <20060208211332.GA8676@hippogriff.physics.drexel.edu> <8f2776cb0602082154q7613a808ha4cff5fa6bbf382b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8f2776cb0602082154q7613a808ha4cff5fa6bbf382b@mail.gmail.com> User-Agent: Mutt/1.5.8i X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00063.txt.bz2 On Wed, Feb 08, 2006 at 09:54:35PM -0800, Jim Blandy wrote: > On 2/8/06, Patrick Alken wrote: > > So it is step #4 that I am hoping someone on the list can give me > > details for. How do you know when all the libraries have been loaded > > so that you can stop execution of the program while you load > > the libs symbol tables? How do you get the pathnames of the libraries > > after they have been loaded so you can mmap them? > > Well, each time it loads a shared library, the dynamic linker calls a > specific function (I think it's _dl_debug_state on Linux), and there > is a designated data structure for you to walk to find the current > list of shlibs. See solib.c and solib-svr4.c. > > But I can't remember, nor can I Google, where this stuff is > documented. I guess we're just depending on undocumented behavior (on > Linux, at least). But the whole reason it's there is to help out the > debugger, so I don't know why it'd be undocumented. Well, that's how _we_ do it. How you're really _supposed_ to do it is unclear, but involves the dynamic DT_DEBUG tag. -- Daniel Jacobowitz CodeSourcery