From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19724 invoked by alias); 2 Mar 2006 00:01:35 -0000 Received: (qmail 19544 invoked by uid 22791); 2 Mar 2006 00:01:33 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 02 Mar 2006 00:01:32 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k2201UeC018191 for ; Wed, 1 Mar 2006 19:01:30 -0500 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 k2201P122976 for ; Wed, 1 Mar 2006 19:01:25 -0500 Received: from localhost.localdomain (vpn50-89.rdu.redhat.com [172.16.50.89]) by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id k2201OkN011735 for ; Wed, 1 Mar 2006 19:01:24 -0500 Received: from ironwood.lan (ironwood.lan [192.168.64.8]) by localhost.localdomain (8.12.11/8.12.10) with ESMTP id k2203NiG007402 for ; Wed, 1 Mar 2006 17:03:23 -0700 Date: Thu, 02 Mar 2006 00:01:00 -0000 From: Kevin Buettner To: gdb-patches@sources.redhat.com Subject: Re: [RFC] Add FR-V Linux core file support Message-ID: <20060301170123.6353b16c@ironwood.lan> In-Reply-To: <20060220153046.GD14155@nevyn.them.org> References: <20060214141016.4e2e56d8@ironwood.lan> <20060220153046.GD14155@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00029.txt.bz2 On Mon, 20 Feb 2006 10:30:46 -0500 Daniel Jacobowitz wrote: > > @@ -421,6 +421,14 @@ frv_current_sos (void) > > struct so_list *sos_head = NULL; > > struct so_list **sos_next_ptr = &sos_head; > > > > + /* Make sure that the main executable has been relocated. Normally > > + this is done by SOLIB_CREATE_INFERIOR_HOOK(), however, this hook > > + is not run when loading core files. Rather than create a new hook, > > + we'll do it here if necessary. */ > > + if (main_executable_lm_info == 0 && core_bfd != NULL) > > + frv_relocate_main_executable (); > > + > > + /* Fetch the GOT corresponding to the main executable. */ > > mgot = main_got (); > > > > /* Locate the address of the first link map struct. */ > > Was this patch written recently, or forward ported from something a > bit older? I'm thinking 2006-01-24 here. The new post_create_inferior > is called when loading core files, and in turn calls > solib_create_inferior_hook. FYI, I just revisited this. post_create_inferior() does indeed cause the main executable to be relocated. However, the shared libraries associated with the post mortem aren't being loaded. (My revised comment below explains why.) Thus, I'm strongly considering retaining the call to solib_relocate_main_executable() (within the current_sos function) and revising the comment as follows: /* Make sure that the main executable has been relocated. This is required in order to find the address of the global offset table, which in turn is used to find the link map info. (See lm_base() for details.) Note that the relocation of the main executable is also performed by SOLIB_CREATE_INFERIOR_HOOK(), however, in the case of core files, this hook is called too late in order to be of benefit to SOLIB_ADD. SOLIB_ADD eventually calls this this function, frv_current_sos, and also precedes the call to SOLIB_CREATE_INFERIOR_HOOK(). (See post_create_inferior() in infcmd.c.) */ The other alternative is to rework post_create_inferior() so that SOLIB_ADD is called after SOLIB_CREATE_INFERIOR_HOOK. According to the comments in post_create_inferior() though, this would not be desirable since SOLIB_ADD might be called without the correct FROM_TTY values. Opinions? Kevin