diff options
author | Tom de Vries <tdevries@suse.de> | 2022-09-07 11:29:11 +0200 |
---|---|---|
committer | Tom de Vries <tdevries@suse.de> | 2022-09-07 11:29:11 +0200 |
commit | 154f2735ad4c2eb0985086b113825e6f4f3abcf1 (patch) | |
tree | 7cbddcb8347a0a6303121e676158866b5e8605cc /sim | |
parent | 0833fb8f4bc8d8f369d0d76f604c248b4ad1de1d (diff) | |
download | fsf-binutils-gdb-154f2735ad4c2eb0985086b113825e6f4f3abcf1.zip fsf-binutils-gdb-154f2735ad4c2eb0985086b113825e6f4f3abcf1.tar.gz fsf-binutils-gdb-154f2735ad4c2eb0985086b113825e6f4f3abcf1.tar.bz2 |
[gdb/testsuite] Fix gdb.ada/access_tagged_param.exp for aarch64
On aarch64-linux, I run into:
...
Breakpoint 2, pck.inspect (obj=0x430eb0 \
<system.pool_global.global_pool_object>, <objL>=0) at pck.adb:17^M
17 procedure Inspect (Obj: access Top_T'Class) is^M
(gdb) FAIL: gdb.ada/access_tagged_param.exp: continue
...
while on x86_64-linux, I see:
...
Breakpoint 2, pck.inspect (obj=0x62b2a0, <objL>=2) at pck.adb:19^M
19 null;^M
(gdb) PASS: gdb.ada/access_tagged_param.exp: continue
...
Note the different line numbers, 17 vs 19.
The difference comes from the gdbarch_skip_prologue implementation.
The amd64_skip_prologue implementation doesn't use gcc line numbers, and falls
back to the architecture-specific prologue analyzer, which correctly skips
past the prologue, to address 0x4022f7:
...
00000000004022ec <pck__inspect>:
4022ec: 55 push %rbp
4022ed: 48 89 e5 mov %rsp,%rbp
4022f0: 48 89 7d f8 mov %rdi,-0x8(%rbp)
4022f4: 89 75 f4 mov %esi,-0xc(%rbp)
4022f7: 90 nop
4022f8: 90 nop
4022f9: 5d pop %rbp
4022fa: c3 ret
...
The aarch64_skip_prologue implementation does use gcc line numbers, which are:
...
File name Line number Starting address View Stmt
pck.adb 17 0x402580 x
pck.adb 17 0x402580 1 x
pck.adb 19 0x40258c x
pck.adb 20 0x402590 x
...
and which are represented like this internally in gdb:
...
INDEX LINE ADDRESS IS-STMT PROLOGUE-END
0 17 0x0000000000402580 Y
1 17 0x0000000000402580 Y
2 19 0x000000000040258c Y
3 20 0x0000000000402590 Y
4 END 0x00000000004025a0 Y
...
The second entry is interpreted as end-of-prologue, so 0x402580 is used, while
the actual end of the prologue is at 0x40258c:
...
0000000000402580 <pck__inspect>:
402580: d10043ff sub sp, sp, #0x10
402584: f90007e0 str x0, [sp, #8]
402588: b90007e1 str w1, [sp, #4]
40258c: d503201f nop
402590: d503201f nop
402594: 910043ff add sp, sp, #0x10
402598: d65f03c0 ret
40259c: d503201f nop
...
Note that the architecture-specific prologue analyzer would have gotten this
right:
...
(gdb) p /x aarch64_analyze_prologue (gdbarch, pc, pc + 128, 0)
$2 = 0x40258c
...
Fix the FAIL by making the test-case more robust against problems in prologue
skipping, by setting the breakpoint on line 19 instead.
Likewise in a few similar test-cases.
Tested on x86_64-linux and aarch64-linux.
Diffstat (limited to 'sim')
0 files changed, 0 insertions, 0 deletions