[ppc64-linux] gdbarch hook to find true execution entry point
Andrew Cagney
ac131313@redhat.com
Fri Jun 27 18:46:00 GMT 2003
>> > --- 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
More information about the Gdb-patches
mailing list