Summary: | [aarch64] Prologue analyzer considers user code part of prologue | ||
---|---|---|---|
Product: | gdb | Reporter: | Tom de Vries <vries> |
Component: | tdep | Assignee: | Luis Machado <luis.machado> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alan.hayward, luis.machado |
Priority: | P2 | ||
Version: | HEAD | ||
Target Milestone: | --- | ||
Host: | aarch64-linux-gnu | Target: | aarch64-linux-gnu |
Build: | aarch64-linux-gnu | Last reconfirmed: |
Description
Tom de Vries
2020-07-29 06:22:48 UTC
aarch64's prologue analyzer considers movz part of the prologue. The problem is that there is no clearly defined boundary of the prologue. We can, however, use a better heuristic to determine when a movz is within the prologue. I have a fix in test. The master branch has been updated by Luis Machado <luisgpm@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f8e3fe0d2764e2976fec6a0ac48921893dc62bbf commit f8e3fe0d2764e2976fec6a0ac48921893dc62bbf Author: Luis Machado <luis.machado@linaro.org> Date: Mon Aug 10 11:56:19 2020 -0300 [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. Fixed with the pushed patch. |