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

[Andrew Cagney <ac131313@redhat.com>]

> Andrew Cagney <ac131313@redhat.com> writes:
> 
> 
>> > 2003-06-11  Jim Blandy  <jimb@redhat.com>
>> > 	* gdbarch.sh (gdbarch_bfd_entry_point): New gdbarch method.
>> > 	* arch-utils.c (generic_bfd_entry_point): New function.
>> > 	* arch-utils.h (generic_bfd_entry_point): New declaration.
>> > 	* gdbarch.c, gdbarch.h: Regenerated.
>> > 	* solib-svr4.c (enable_break): Call it, instead of accessing
>> > 	tmp_bfd->start_address directly.
>> >
> 
>> I think this should be in BFD.  Not just GDB but also the simulators
>> are going to need this information.
> 
> 
> Not sure I agree.  The interesting information for process startup is
> intrinsically ABI-specific; for PPC64 Linux it's the TOC and
> environment pointers, but for another target it might be something
> else.  You need ABI-specific code on the consumer's side anyway, just
> to know, for example, which registers everything goes in, so as long
> as that's there anyway, why not let BFD stick to what it does best ---
> interpreting object files?

not forgettting architecture, disassembler, minimal symbols, ...

> In general, the code in GDB supporting an ABI needs to be able to
> provide its own code to interpret what comes out of BFD.  This is just
> one case that wasn't covered --- thus the gdbarch method.

 From my PS:

>   I think this should be in BFD.  Not just GDB but also the simulators are going to need this information.
> 
> PS: If BFD does this, ENTRY_POINT_ADDRESS can also, finally, be deleted.

The above and CALL_DUMMY_ADDRESS are effecively doing the same thing - 
returning the entry-point address.  If nothing else, some juggling will 
let them share a common architecture method and avoid this duplication.

Anyway, I still think it's better to have it available in bfd (where the 
sim can use it).

Andrew