From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20040 invoked by alias); 9 Oct 2003 19:58:14 -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 20032 invoked from network); 9 Oct 2003 19:58:13 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 Oct 2003 19:58:13 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h99JwCM21807 for ; Thu, 9 Oct 2003 15:58:12 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h99JwCc07148 for ; Thu, 9 Oct 2003 15:58:12 -0400 Received: from localhost.localdomain (vpn50-39.rdu.redhat.com [172.16.50.39]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id h99JwBdT021493; Thu, 9 Oct 2003 15:58:11 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h99Jw5214116; Thu, 9 Oct 2003 12:58:05 -0700 Date: Thu, 09 Oct 2003 19:58:00 -0000 From: Kevin Buettner Message-Id: <1031009195805.ZM14115@localhost.localdomain> In-Reply-To: Roland McGrath "Re: unwind support for Linux 2.6 vsyscall DSO" (Oct 6, 9:45pm) References: <200310070445.h974jrd1020409@magilla.sf.frob.com> To: Roland McGrath , Jim Blandy Subject: Re: unwind support for Linux 2.6 vsyscall DSO Cc: Elena Zannoni , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00311.txt.bz2 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(). Kevin