aarch64-tdep.c:aarch64_skip_prologue oddity, what's going on???

aarch64-tdep.c:aarch64_skip_prologue oddity, what's going on???

[Doug Evans]

Hi.

I'm trying to fix a few clang-related testsuite failures.
amd64,i386,arm have checks for symtab->producer == clang,
and the problem is this code doesn't check whether
symtab->language == language_asm.
I could fix the bug in all three places, but I think some consolidation
is in order here (I'd rather fix it in one place instead of three).

However, digging deeper I've found something I don't understand.

Consider aarch64-tdep.c:aarch64_skip_prologue,
though several arches do similar things:
[basically, grep for all *-tdep.c files that have two calls
to skip_prologue_using_sal]

static CORE_ADDR
aarch64_skip_prologue (struct gdbarch *gdbarch, CORE_ADDR pc)
{
  unsigned long inst;
  CORE_ADDR skip_pc;
  CORE_ADDR func_addr, limit_pc;
  struct symtab_and_line sal;

  /* 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);
    }

  /* Can't determine prologue from the symbol table, need to examine
     instructions.  */

  /* Find an upper limit on the function prologue using the debug
     information.  If the debug information could not be used to
     provide that bound, then use an arbitrary large number as the
     upper bound.  */
  limit_pc = skip_prologue_using_sal (gdbarch, pc);
  if (limit_pc == 0)
    limit_pc = pc + 128;	/* Magic.  */

  /* Try disassembling prologue.  */
  return aarch64_analyze_prologue (gdbarch, pc, limit_pc, NULL);
}

I've got several questions here, but some of them may be moot
depending on the answers to others, so I'm going to begin slowly.

I guess my first question is: Under what circumstances
does the above call to find_pc_partial_function return a value
for FUNC_ADDR that is not equal to PC?

I realize that in the general case, if I pass, e.g., "main+1" for PC
then find_pc_partial_function will return "main" for FUNC_ADDR.
But when will gdb call gdbarch_skip_prologue with a pc value
that is not the start of a function?

I realize skip_prologue_sal has this:

      /* Skip "first line" of function (which is actually its prologue).  */
      pc += gdbarch_deprecated_function_start_offset (gdbarch);
      if (gdbarch_skip_entrypoint_p (gdbarch))
        pc = gdbarch_skip_entrypoint (gdbarch, pc);
      if (skip)
	pc = gdbarch_skip_prologue (gdbarch, pc);

gdbarch_deprecated_function_start_offset is only set by vax-tdep.c.
gdbarch_skip_entrypoint is only set by ppc-linux-tdep.c.
So for these two arches gdbarch_skip_prologue can be called
with a pc value greater than the function start address,
but how about every other arch?

I guess I'm missing something, I'm curious what it is.

My second question concerns the above two calls to skip_prologue_using_sal
in aarch64-tdep.c:aarch64_skip_prologue.
The first thing skip_prologue_using_sal does is call
find_pc_partial_function (which is kinda disappointing because we
just called it), and if that call fails I think
skip_prologue_using_sal will end up returning zero.
[btw, shouldn't skip_prologue_using_sal check the return code of
find_pc_partial_function?]

So, second question: Can we remove both the above call to
find_pc_partial_function, and the second call to skip_prologue_using_sal?
Or, under what circumstances will the second call to
skip_prologue_using_sal return a non-zero value?

I've got some experiments to try to shed some light on this,
but if anyone has any state they can share, that'd be great.

Thanks.

Re: aarch64-tdep.c:aarch64_skip_prologue oddity, what's going on???

[Doug Evans]

On Tue, Aug 26, 2014 at 5:58 PM, Doug Evans <dje@google.com> wrote:
> Hi.
>
> I'm trying to fix a few clang-related testsuite failures.
> amd64,i386,arm have checks for symtab->producer == clang,
> and the problem is this code doesn't check whether
> symtab->language == language_asm.
> I could fix the bug in all three places, but I think some consolidation
> is in order here (I'd rather fix it in one place instead of three).

OTOH, I can see an argument for skip_prologue_using_sal to early exit
for assembler.
I still think some consolidation is in order though.
And my questions regarding gdbarch_skip_prologue oddities are still open.

Re: aarch64-tdep.c:aarch64_skip_prologue oddity, what's going on???

[Yao Qi]

Doug Evans <dje@google.com> writes:

> So, second question: Can we remove both the above call to
> find_pc_partial_function, and the second call to skip_prologue_using_sal?
> Or, under what circumstances will the second call to
> skip_prologue_using_sal return a non-zero value?

Is it https://www.sourceware.org/ml/gdb/2008-09/msg00111.html the case?
The fix is about ARM, but looks the problem is arch independent.

-- 
Yao (齐尧)

Re: aarch64-tdep.c:aarch64_skip_prologue oddity, what's going on???

[Doug Evans]

Yao Qi writes:
 > Doug Evans <dje@google.com> writes:
 > 
 > > So, second question: Can we remove both the above call to
 > > find_pc_partial_function, and the second call to skip_prologue_using_sal?
 > > Or, under what circumstances will the second call to
 > > skip_prologue_using_sal return a non-zero value?
 > 
 > Is it https://www.sourceware.org/ml/gdb/2008-09/msg00111.html the case?
 > The fix is about ARM, but looks the problem is arch independent.

Thanks!

I looked at this and I'm still confused why the code is the way it is,
it seems unnecessarily complex (not massively so of course, just that
some useful simplification is possible (I think!).

I've got a patch to post.
Hopefully it will help someone clear things up.