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.dwarf2/dw2-dir-file-name.exp
Date: Fri, 12 Aug 2022 09:48:26 +0000 (GMT)	[thread overview]
Message-ID: <20220812094826.784553858C52@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=cd919f5533cc8aa495acd75a6f059e5fcf2e6af9

commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9
Author: Tom de Vries <tdevries@suse.de>
Date:   Fri Aug 12 11:48:21 2022 +0200

    [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
    
    When running test-case gdb.dwarf2/dw2-dir-file-name.exp on x86_64-linux, we
    have:
    ...
    (gdb) break compdir_missing__ldir_missing__file_basename^M
    Breakpoint 2 at 0x4004c4: file tmp-dw2-dir-file-name.c, line 999.^M
    (gdb) continue^M
    Continuing.^M
    ^M
    Breakpoint 2, 0x00000000004004c4 in \
      compdir_missing__ldir_missing__file_basename () \
      at tmp-dw2-dir-file-name.c:999^M
    (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: \
      compdir_missing__ldir_missing__file_basename: continue to breakpoint: \
      compdir_missing__ldir_missing__file_basename
    ...
    
    When trying to set a breakpoint on
    compdir_missing__ldir_missing__file_basename, the architecture-specific
    prologue skipper starts at 0x4004c0 and skips past two insns, to 0x4004c4:
    ...
    00000000004004c0 <compdir_missing__ldir_missing__file_basename>:
      4004c0: 55                      push   %rbp
      4004c1: 48 89 e5                mov    %rsp,%rbp
      4004c4: 8b 05 72 1b 20 00       mov    0x201b72(%rip),%eax        # 60203c <v>
      4004ca: 83 c0 01                add    $0x1,%eax
      4004cd: 89 05 69 1b 20 00       mov    %eax,0x201b69(%rip)        # 60203c <v>
      4004d3: 90                      nop
      4004d4: 5d                      pop    %rbp
      4004d5: c3                      ret
    ...
    
    And because the line table info is rudamentary:
    ...
    CU: tmp-dw2-dir-file-name.c:
    File name                    Line number    Starting address    View    Stmt
    tmp-dw2-dir-file-name.c              999            0x4004c0               x
    tmp-dw2-dir-file-name.c             1000            0x4004d6               x
    tmp-dw2-dir-file-name.c                -            0x4004d6
    ...
    the address does not fall at an actual line, so the breakpoint is shown with
    address, both when setting it and hitting it.
    
    when running the test-case with aarch64-linux, we have similarly:
    ...
    (gdb) break compdir_missing__ldir_missing__file_basename^M
    Breakpoint 2 at 0x400618: file tmp-dw2-dir-file-name.c, line 999.^M
    ...
    due to the architecture-specific prologue skipper starting at 0x400610 and
    skipping past two insns, to 0x400618:
    ...
    0000000000400610 <compdir_missing__ldir_missing__file_basename>:
      400610:       90000100        adrp    x0, 420000 <__libc_start_main@GLIBC_2.17>
      400614:       9100b000        add     x0, x0, #0x2c
      400618:       b9400000        ldr     w0, [x0]
      40061c:       11000401        add     w1, w0, #0x1
      400620:       90000100        adrp    x0, 420000 <__libc_start_main@GLIBC_2.17>
      400624:       9100b000        add     x0, x0, #0x2c
      400628:       b9000001        str     w1, [x0]
      40062c:       d503201f        nop
      400630:       d65f03c0        ret
    ...
    
    But interestingly, the aarch64 architecture-specific prologue skipper is
    wrong.  There is no prologue, and the breakpoint should be set at 0x400610.
    
    By using "break *compdir_missing__ldir_missing__file_basename"
    we can get the breakpoint set at 0x400610:
    ...
    (gdb) break *compdir_missing__ldir_missing__file_basename^M
    Breakpoint 2 at 0x400610: file tmp-dw2-dir-file-name.c, line 999.^M
    ...
    and make the test-case independent of prologue analysis.
    
    This requires us to update the expected patterns.
    
    The fix ensures that once the aarch64 architecture-specific prologue skipper
    will be fixed, this test-case won't start failing.
    
    Tested on x86_64-linux.

Diff:
---
 gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
 gdb/testsuite/lib/gdb.exp                      | 7 ++++++-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
index 4d3f767f597..4c4c1ff07af 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
@@ -396,20 +396,20 @@ proc test { func compdir filename } {
 	    error "not absolute"
 	}
 
-	gdb_breakpoint $func
+	gdb_breakpoint *$func
 	gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
 
 	gdb_test_no_output "set filename-display absolute"
 	verbose -log "expect: ${absolute}"
-	gdb_test "frame" " in $func \\(\\) at [string_to_regexp ${absolute}]:999" "absolute"
+	gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp ${absolute}]:999" "absolute"
 
 	gdb_test_no_output "set filename-display basename"
 	verbose -log "expect: [file tail $filename]"
-	gdb_test "frame" " in $func \\(\\) at [string_to_regexp [file tail $filename]]:999" "basename"
+	gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp [file tail $filename]]:999" "basename"
 
 	gdb_test_no_output "set filename-display relative"
 	verbose -log "expect: $filename"
-	gdb_test "frame" " in $func \\(\\) at [string_to_regexp $filename]:999" "relative"
+	gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp $filename]:999" "relative"
     }
 }
 
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index a8f25b5f0dd..70fc019eeb9 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -787,9 +787,14 @@ proc gdb_continue_to_breakpoint {name {location_pattern .*}} {
     global gdb_prompt
     set full_name "continue to breakpoint: $name"
 
+    set re_at_in " (at|in) "
+    if { [regexp $re_at_in $location_pattern] } {
+	set re_at_in " "
+    }
+
     set kfail_pattern "Process record does not support instruction 0xfae64 at.*"
     gdb_test_multiple "continue" $full_name {
-	-re "(?:Breakpoint|Temporary breakpoint) .* (at|in) $location_pattern\r\n$gdb_prompt $" {
+	-re "(?:Breakpoint|Temporary breakpoint) .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
 	    pass $full_name
 	}
 	-re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" {


                 reply	other threads:[~2022-08-12  9:48 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=20220812094826.784553858C52@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: link
Be 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).