[PATCH] Remove some obfuscation from ${arch}_skip_prologue functions
Doug Evans
dje@google.com
Wed Sep 3 17:19:00 GMT 2014
On Tue, Sep 2, 2014 at 4:53 PM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> This patch is a follow up to an observation made here:
> https://sourceware.org/ml/gdb-patches/2014-08/msg00539.html
>
> [...]
>
> At the very least, I'd like to document Why Things Are The Way They Are
> if there is indeed a reason for it.
>
> [...]
btw, there is still one aspect here that I don't understand the WHY of:
aarch64-tdep.c and others do this (grep for <<<<):
/* See if we can determine the end of the prologue via the symbol
table. If so, then return either PC, or the PC after the
prologue, whichever is greater. */
if (find_pc_partial_function (pc, NULL, &func_addr, NULL))
{
CORE_ADDR post_prologue_pc
= skip_prologue_using_sal (gdbarch, func_addr);
if (post_prologue_pc != 0)
return max (pc, post_prologue_pc); //<<<<
}
Why? Why max (pc, post_prologue_pc) ?
Is it because ${arch}_skip_prologue can be called
with a pc value greater than the start address of the function?
If so, when?
Are people just being conservative because it's not clear
what values of pc may be passed to ${arch}_skip_prologue?
[If so we've got unnecessarily complex code due to unclear APIs ... bleah.]
N.B. There are only two arches that I could find where
(I think) the pc passed to ${arch}_skip_prologue could
be different than the function's entry point:
1) vax, which sets deprecated_function_start_offset
2) ppc-linux (elf v2), which sets skip_entrypoint
If I'm missing something ... great ... let's get it documented.
[And if it is documented, let's make it easier to find. :-)
The prologue stuff I can find from the Internals Wiki doesn't
discuss this, and I wasn't about to read the entire wiki
looking for it.]
More information about the Gdb-patches
mailing list