Re: [PATCH] Remove some obfuscation from ${arch}_skip_prologue functions

[Doug Evans <dje@google.com>]

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.]