From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21435 invoked by alias); 9 Oct 2003 20:02:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 21427 invoked from network); 9 Oct 2003 20:02:32 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 9 Oct 2003 20:02:32 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A7gzQ-0005Uc-TZ; Thu, 09 Oct 2003 16:02:24 -0400 Date: Thu, 09 Oct 2003 20:02:00 -0000 From: Daniel Jacobowitz To: Kevin Buettner Cc: Roland McGrath , Jim Blandy , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO Message-ID: <20031009200224.GA21068@nevyn.them.org> Mail-Followup-To: Kevin Buettner , Roland McGrath , Jim Blandy , Elena Zannoni , gdb-patches@sources.redhat.com References: <200310070445.h974jrd1020409@magilla.sf.frob.com> <1031009195805.ZM14115@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1031009195805.ZM14115@localhost.localdomain> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-10/txt/msg00313.txt.bz2 On Thu, Oct 09, 2003 at 12:58:05PM -0700, Kevin Buettner wrote: > On Oct 6, 9:45pm, Roland McGrath wrote: > > > Ok, good. Are people then agreed that adding a Linux-specific SOLIB_ADD > > that does this stuff in addition to calling solib_add is the way to go? > > I do not want to see a linux-specific SOLIB_ADD added to gdb. I'm > (still) trying to collapse all of the various SOLIB_ADD's down to just > one function. Progress has been slow, but it's being made. > > Adding a call to a new gdbarch method in solib_add() (in solib.c) > might be acceptable. This method could be set up in the > {$arch}-linux-tdep.c files. > > However, before going this route (adding a new gdbarch method), I'd > prefer that you look at TARGET_SO_SPECIAL_SYMBOL_HANDLING() to see if > it could be used to serve your purposes. If it can't, then you should > consider adding a new TARGET_SO_... method which is called from > solib_add(). In either case, the hook for setting up a call to some > linux-specific code from solib-svr4.c could be done in a manner > similar that used to set the link map offsets fetcher. See > set_solib_svr4_fetch_link_map_offsets() in solib-svr4.[hc]. > > To recap, here are my preferences (from most to least preferable): > > - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work. (It's > already called by solib_add.) > - Add a new TARGET_SO_... method which is called from solib_add(). > - Add a new gdbarch method which is called from solib_add(). The problem with using SOLIB_ADD for this is that we can't SOLIB_ADD safely till we hit the dynamic linker breakpoint, but it would be _really_ nice to be able to load this object right after the inferior starts (and for static binaries, etc etc). How would you suggets we do that? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer