This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [ppc64-linux] gdbarch hook to find true execution entry point
On Jun 13, 5:32pm, Jim Blandy wrote:
> > 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?
I probably missed the comment in your original patch. But what you
wrote below looks good to me.
> + # 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
>
> Revised patch:
>
> 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.
The solib-svr4.c change is okay with me. If you can get Andrew on board
for the gdbarch changes, you're good to go. If you wind up implementing
it in bfd, consider the solib change to be pre-approved.
Kevin