[AArch64] Improve prologue handling (and fix PR26310)
authorLuis Machado <luis.machado@linaro.org>
Mon, 10 Aug 2020 14:56:19 +0000 (11:56 -0300)
committerLuis Machado <luis.machado@linaro.org>
Mon, 10 Aug 2020 14:56:19 +0000 (11:56 -0300)
commitf8e3fe0d2764e2976fec6a0ac48921893dc62bbf
tree1d11b79297b0789d4af22f4ff6ca50288c2d13c3
parentcc308722fba3741a26993afe029078571604c2bd
[AArch64] Improve prologue handling (and fix PR26310)

I initially noticed the problem with the addition of
gdb.dwarf2/dw2-line-number-zero.exp.  The following failures showed up:

FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next

They happen because AArch64's prologue analyzer skips too many instructions
and ends up indicating a stopping point further into user code.

Dump of assembler code for function bar1:
   0x00000000000006f8 <+0>: stp x29, x30, [sp, #-16]!
   0x00000000000006fc <+4>: mov x29, sp
   0x0000000000000700 <+8>: mov w0, #0x1                    // #1
   0x0000000000000704 <+12>: bl 0x6e4 <foo>
   0x0000000000000708 <+16>: mov w0, #0x2                    // #2

We should've stopped at 0x700, but the analyzer actually skips
that instruction and stops at 0x704.  Then GDB ends up adjusting
the address further, and pushes the stopping point to 0x708 based on the
SAL information.

I'm not sure if this adjustment to 0x708 is correct though, as it ends up
skipping past a branch. But I'm leaving that aside for now.

One other complicating factor is that GCC seems to be hoisting up instructions
from user code, mixing them up with prologue instructions.

The following patch adjusts the heuristics a little bit, and tracks when the
SP and FP get used.  If we notice an instruction that is not supposed to be
in the prologue, and this happens *after* SP/FP adjustments and saving of
registers, we stop the analysis.

This means, for PR26310, that we will now stop at 0x700.

I've also added a few more unit tests to make sure the updated behavior is
validated.

gdb/ChangeLog:

2020-08-10  Luis Machado  <luis.machado@linaro.org>

PR gdb/26310

* aarch64-tdep.c (aarch64_analyze_prologue): Track use of SP/FP and
act accordingly.
(aarch64_analyze_prologue_test): Add more unit tests to exercise
movz/str/stur/stp skipping behavior.
gdb/ChangeLog
gdb/aarch64-tdep.c