From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 509 invoked by alias); 9 Oct 2003 22:32:26 -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 482 invoked from network); 9 Oct 2003 22:32:21 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 Oct 2003 22:32:21 -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 h99MWLM13417 for ; Thu, 9 Oct 2003 18:32:21 -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 h99MWLc04689 for ; Thu, 9 Oct 2003 18:32:21 -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 h99MWJdT010460; Thu, 9 Oct 2003 18:32:19 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h99MWEe14831; Thu, 9 Oct 2003 15:32:14 -0700 Date: Thu, 09 Oct 2003 22:32:00 -0000 From: Kevin Buettner Message-Id: <1031009223213.ZM14830@localhost.localdomain> In-Reply-To: Roland McGrath "Re: unwind support for Linux 2.6 vsyscall DSO" (Oct 9, 3:07pm) References: <200310092207.h99M7jr4010466@magilla.sf.frob.com> To: Roland McGrath , Kevin Buettner Subject: Re: unwind support for Linux 2.6 vsyscall DSO Cc: Jim Blandy , Elena Zannoni , gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-10/txt/msg00326.txt.bz2 On Oct 9, 3:07pm, Roland McGrath wrote: > > 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. I was suggesting a hook or hooks, (using a mechanisms similar to set_solib_svr4_fetch_link_map_offsets() for setting up the hook) to be used either with existing or new TARGET_SO_* methods. It sounds like this won't be sufficient for your purposes though. I see you've sent some other mail on this matter. I'll reply further there. Kevin