This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [ppc64-linux]: correctly find a BFD's code entry point address
- From: Kevin Buettner <kevinb at redhat dot com>
- To: Jim Blandy <jimb at redhat dot com>, gdb-patches at sources dot redhat dot com
- Date: Thu, 12 Jun 2003 22:45:24 -0700
- Subject: Re: [ppc64-linux]: correctly find a BFD's code entry point address
- References: <vt2wufqsxet.fsf@zenia.home>
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