From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23554 invoked by alias); 9 Oct 2003 22:07:50 -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 23539 invoked from network); 9 Oct 2003 22:07:47 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sources.redhat.com with SMTP; 9 Oct 2003 22:07:47 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 8EF48357B; Thu, 9 Oct 2003 15:07:46 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id h99M7kN2010470; Thu, 9 Oct 2003 15:07:46 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id h99M7jr4010466; Thu, 9 Oct 2003 15:07:45 -0700 Date: Thu, 09 Oct 2003 22:07:00 -0000 Message-Id: <200310092207.h99M7jr4010466@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Kevin Buettner Cc: Jim Blandy , Elena Zannoni , gdb-patches@sources.redhat.com Subject: Re: unwind support for Linux 2.6 vsyscall DSO In-Reply-To: Kevin Buettner's message of Thursday, 9 October 2003 12:58:05 -0700 <1031009195805.ZM14115@localhost.localdomain> X-Shopping-List: (1) Scenic horrendous honkers (2) Dyspeptic imprudent ripping-cats (3) Naugahyde Digressions X-SW-Source: 2003-10/txt/msg00322.txt.bz2 > 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. Ok, glad to hear it. The mess there now was less than inspiring. It's pretty damn confusing figuring out when CLEAR_SOLIB gets called for one thing (and when clear_solib does but not CLEAR_SOLIB!). > 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(). None of those hooks is in quite the right place, so we'll need a new one. > 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]. Is this in the context of a new TARGET_SO_* hook or without it? The fetch_link_map_offsets thing is some special magic internal to solib-svr4.c and not matched with a target_so_ops hook. Are you talking about replicating that? A new target_so_ops hook is needed to get called in the right places. That being the case, are you suggesting a set_solib_svr4_new_hook_name that changes svr4_so_ops.new_hook_name? Or what exactly? We also need to do something at clear_solib time. There is a target_so_ops hook for that already, but we need to call the old svr4_clear_solib as well as do the new linux-specific work. > - See if TARGET_SO_SPECIAL_SYMBOL_HANDLING can be made to work. (It's > already called by solib_add.) It's only called if other symbols were loaded. So at startup it won't be called, and if `set auto-solib-add 0' has been done it won't ever be called. > - Add a new TARGET_SO_... method which is called from solib_add(). Unless solib_add is changed to call TARGET_SO_SPECIAL_SYMBOL_HANDLING unconditionally, we need something new. > - Add a new gdbarch method which is called from solib_add(). There are so many different function tables in gdb, I haven't the foggiest idea how this meaningfully differs from target_so_ops additions. I certainly don't know any reasons to prefer the gdbarch flavor if you find it less preferable.