This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


- 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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]