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

[Andrew Cagney <ac131313 at redhat dot com>]

> > > --- 1022,1029 ----
> > >   	 the current pc (which should point at the entry point for the
> > >   	 dynamic linker) and subtracting the offset of the entry point.  */
> > >         if (!load_addr_found)
> > > ! 	load_addr = (read_pc ()
> > > !                      - generic_bfd_entry_point (current_gdbarch, tmp_bfd));
> > >   
> > >         /* Record the relocated start and end address of the dynamic linker
> > >            text and plt section for svr4_in_dynsym_resolve_code.  */
>
> > Shouldn't enable_break() in solib-svr4.c be calling
> > gdbarch_bfd_entry_point()?
>
>
> Actually, the overhead of the indirect function call would be a
> serious performance problem here.  And since using any target other
> than PPC64 indicates major pilot error to begin with, I think it's
> better that we catch that problem early by having GDB fail at this
> point than just paper over the problem by allowing other targets to
> function properly.  Allowing GDB to run "correctly" on those systems
> only creates the illusion that they are adequate for real work.

Um, I don't understand this paragraph at all.  Which `indirect function 
call would be a serious performance problem here'?

> (Um, yes, thanks for catching that.)
>
>
> > What cases do you know of where calling bfd_get_start_address() is
> > insufficient for finding the start address?  I'm wondering if we
> > need a gdbarch hook at all...
>
>
> The comment on the gdbarch.sh entry is supposed to explain why it's
> necessary.  I've expanded it a bit; is it clearer?  Is there someplace
> else I should put it?
>
> + # 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.

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?

- 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?

- 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.

Andrew