Re: [ppc64-linux]: correctly find a BFD's code entry point address

[Kevin Buettner <kevinb@redhat.com>]

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