From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5947 invoked by alias); 13 Jun 2003 05:45:33 -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 5843 invoked from network); 13 Jun 2003 05:45:29 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Jun 2003 05:45:29 -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 h5D5jUH27381 for ; Fri, 13 Jun 2003 01:45:30 -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 h5D5jUI09219 for ; Fri, 13 Jun 2003 01:45:30 -0400 Received: from localhost.localdomain (vpn50-31.rdu.redhat.com [172.16.50.31]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h5D5jTe31542; Fri, 13 Jun 2003 01:45:29 -0400 Received: (from kev@localhost) by localhost.localdomain (8.11.6/8.11.6) id h5D5jOL00347; Thu, 12 Jun 2003 22:45:24 -0700 Date: Fri, 13 Jun 2003 05:45:00 -0000 From: Kevin Buettner Message-Id: <1030613054523.ZM346@localhost.localdomain> In-Reply-To: Jim Blandy "[ppc64-linux]: correctly find a BFD's code entry point address" (Jun 12, 6:12pm) References: To: Jim Blandy , gdb-patches@sources.redhat.com Subject: Re: [ppc64-linux]: correctly find a BFD's code entry point address MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00458.txt.bz2 On Jun 12, 6:12pm, Jim Blandy wrote: > + /* Return the unrelocated code address at which execution begins for > + ABFD, under the 64-bit PowerPC Linux ABI. On that system, the ELF > + header e_entry field (which is what bfd_get_start_address gives > + you) is the address of the function descriptor for the startup > + function, not the address of the actual machine instruction you > + jump to. > + > + This function doesn't just go and read the entry point from the > + function descriptor. We need it to work when ABFD is the dynamic > + linker, immediately after an exec. But ld.so is a dynamic > + executable itself on PPC64 Linux, so it appears in memory whereever > + the kernel drops it; this means that bfd_get_start_address's result > + needs to be adjusted --- by some offset we don't know. So we can't > + find the descriptor's address in memory to read the entry point > + from it. > + > + Instead, we do it all based on ABFD's symbol table. We take the > + address from bfd_get_start_address, find each symbol at that > + address, stick a '.' on the front of its name to get the entry > + point symbol name, try to look that up, and return the value of > + what we find, if anything. We never touch memory, or talk with the > + kernel about the inferior at all. > + > + Now, this address we return is straight from the symbol table, so > + it hasn't been adjusted to take into account where ABFD was loaded. > + But that's okay --- our job is just to return the unrelocated code > + address. */ This approach strikes me as somewhat more complicated (and fragile) than need be. I think it would be preferable to simply fetch the necessary bytes from the address given by bfd_get_start_address in the executable (or object) file. Nice description though; I really appreciate comments like this. Kevin