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

[Andrew Cagney <ac131313@redhat.com>]

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

Unfortunatly, a number of targets, such as PowerPC 64 GNU/Linux, have 
added custom CALL_DUMMY_ADDRESS methods :-(

My original concern here was that CALL_DUMMY_ADDRESS, 
CONVERT_FROM_FUNC_PTR_ADDR, and this new architecture method all 
appeared to be doing roughly the same thing.

Can at PowerPC 64 GNU/Linux's CALL_DUMMY_ADDRESS be eliminated?

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

So technically, CONVERT_FROM_FUNC_PTR_ADDR should be modified to take a 
memory accessor method (bfd or the target).  That would require a major 
target stack overhaul though, outch :-(

This leaves either GDB or BFD needing this method.  I guess, for the 
moment, GDB gets it, but can it at least be called something meaningful?

A guess is CONVERT_FROM_BFD_CODE_PTR_ADDR(entry_point, bfd)?  Better? 
ENTRY_POINT_FROM_BFD? (I believe FUNC in the above should have been CODE?).

Your also going to need documentation.

Andrew