public inbox for gdb-cvs@sourceware.org help / color / mirror / Atom feed
From: Tom de Vries <vries@sourceware.org> To: gdb-cvs@sourceware.org Subject: [binutils-gdb] [gdb/testsuite] Fix gdb.ada/access_tagged_param.exp for aarch64 Date: Wed, 7 Sep 2022 09:29:17 +0000 (GMT) [thread overview] Message-ID: <20220907092918.08FCB3858D28@sourceware.org> (raw) https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=154f2735ad4c2eb0985086b113825e6f4f3abcf1 commit 154f2735ad4c2eb0985086b113825e6f4f3abcf1 Author: Tom de Vries <tdevries@suse.de> Date: Wed Sep 7 11:29:11 2022 +0200 [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. Diff: --- gdb/testsuite/gdb.ada/access_tagged_param.exp | 2 +- gdb/testsuite/gdb.ada/ptype_tagged_param.exp | 2 +- gdb/testsuite/gdb.ada/ref_param.exp | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/gdb/testsuite/gdb.ada/access_tagged_param.exp b/gdb/testsuite/gdb.ada/access_tagged_param.exp index 2b8e8ef172f..931c7fb12a9 100644 --- a/gdb/testsuite/gdb.ada/access_tagged_param.exp +++ b/gdb/testsuite/gdb.ada/access_tagged_param.exp @@ -33,7 +33,7 @@ if ![runto "foo"] then { return } -gdb_breakpoint "pck.inspect" +gdb_breakpoint "pck.adb:19" # Continue until we reach the breakpoint, and verify that we can print # the value of all the parameters. diff --git a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp index 0972e02a636..3a4a84a22ce 100644 --- a/gdb/testsuite/gdb.ada/ptype_tagged_param.exp +++ b/gdb/testsuite/gdb.ada/ptype_tagged_param.exp @@ -27,7 +27,7 @@ set has_runtime_debug_info [gnat_runtime_has_debug_info] clean_restart ${testfile} -if ![runto "position_x" ] then { +if ![runto "pck.adb:20" ] then { return -1 } diff --git a/gdb/testsuite/gdb.ada/ref_param.exp b/gdb/testsuite/gdb.ada/ref_param.exp index cbe0c065d34..56347932564 100644 --- a/gdb/testsuite/gdb.ada/ref_param.exp +++ b/gdb/testsuite/gdb.ada/ref_param.exp @@ -25,7 +25,7 @@ if {[gdb_compile_ada "${srcfile}" "${binfile}" executable [list debug ]] != "" } clean_restart ${testfile} -if ![runto call_me] then { +if ![runto pck.adb:20] then { perror "Couldn't run ${testfile}" return }
reply other threads:[~2022-09-07 9:29 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20220907092918.08FCB3858D28@sourceware.org \ --to=vries@sourceware.org \ --cc=gdb-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).