Re: [ppc64-linux] gdbarch hook to find true execution entry point

[Jim Blandy <jimb@redhat.com>]

Andrew Cagney <ac131313@redhat.com> writes:
> > + # The actual instruction address at which ABFD would begin
> > execution.
> > + # If ABFD is position-independent code, this address is not relocated;
> > + # it's the address at which execution would begin if the file were
> > + # loaded at its sections' vmas.
> > + # + # On most architectures, this is simply bfd_get_start_address.
> > But on
> > + # some (like 64-bit PPC), that points to a function descriptor, not an
> > + # instruction.  The descriptor contains the actual entry point, and
> > + # other pointers needed to call the function.
> > + m:1::CORE_ADDR:bfd_entry_point:bfd *abfd:abfd:::generic_bfd_entry_point::0
> 
> So, given a function descriptor at VMA bfd_get_start_address(), there
> are two possible code addresses:
> 
> - The relocated address found by reading the descriptor from the target.
> This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), target memory)?
> 
> - The un-relocated address found by reading the descriptor from the bfd.
> This is CONVERT_FROM_FUNC_PTR_ADDR (bfd_get_start_address(), use bfd
> memory)?
> 
> and the two values are different.  Hence the new method.

That's the important difference, yes.  The trick the solib code uses
to find the dynamic linker's load offset really does need the
unrelocated address --- the amount by which it would need to be
relocated is exactly what we're computing there.

> Several things I'm still missing though:
> 
> - Is entry_point_address wrong?
> "symfile.c" sets it to bfd_get_start_address() so (ignoring ppc64
> linux), and given an dynamic executable, won't it too need
> relocating?

Yes, it will need relocation.  Executables always used to load at
fixed addresses; now they're becoming relocatable to make
buffer-overflow attacks harder.  So this is a new issue.

> - Does svr4_relocate_main_executable need to be changed?
> It is playing with:
>    interp_sect = bfd_get_section_by_name (exec_bfd, ".interp");
>    if (interp_sect == NULL
>        && (bfd_get_file_flags (exec_bfd) & DYNAMIC) != 0
>        && bfd_get_start_address (exec_bfd) != pc)
> and then:
>        displacement = pc - bfd_get_start_address (exec_bfd);
> and my understanding of the above suggests that it too needs
> changing. Hmm, interp_sect is probably non-NULL so the test would
> fail, but for consistency?

Yes, that should call gdbarch_bfd_entry_point too --- thanks for
catching that.

> - Can infcall.c instead explicitly call CONVERT_FROM_FUNC_PTR_ADDR on
> CALL_DUMMY_ADDRESS, or better, have entry_point_address do this?  It
> would help eliminate CALL_DUMMY_ADDRESS.

I'm not sure I understand enough of the details to say anything about
this.  Why isn't infcall.c just using entry_point_address right now?