public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Carl Love <cel@us.ibm.com>
To: Luis Machado <luis.machado@arm.com>,
	Tom de Vries <tdevries@suse.de>,
	gdb-patches@sourceware.org
Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
Date: Mon, 15 Aug 2022 09:01:57 -0700	[thread overview]
Message-ID: <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com> (raw)
In-Reply-To: <d5ae6860-2625-432f-c927-60028335ff66@arm.com>


Tom:

Looks like the patch was applied last Friday.  We are now seeing 129
test failures related to this commit on PowerPC.  The failures are seen
on Power 8, 9 and 10.

Here is an initial bit of the failures:

...
Breakpoint 2 at 0x100006e0: file tmp-dw2-dir-file-name.c, line 999.
(gdb) continue
Continuing.
[Inferior 1 (process 2520351) exited normally]
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename (the program exited)
set filename-display absolute
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: set filename-display absolute
expect: /home/carll/GDB/build-current/gdb/testsuite/outputs/gdb.dwarf2/dw2-dir-file-name/dw2-dir-file-name.d/rdir/tmp-dw2-dir-file-name.c
frame
No stack.
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: absolute
set filename-display basename
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: set filename-display basename
expect: tmp-dw2-dir-file-name.c
frame
No stack.
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: basename
set filename-display relative
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: set filename-display relative
expect: tmp-dw2-dir-file-name.c
frame
No stack.
(gdb) FAIL: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: relative
set directories
(gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_relative: set directories
break *compdir_missing__ldir_missing__file_relative
Breakpoint 3 at 0x10000728: file fdir/tmp-dw2-dir-file-name.c, line 999.
(gdb) continue
The program is not being run.

etc.

		=== gdb Summary ===

# of expected passes		129
# of unexpected failures	128

I have not had time yet to try and dig into the failures to figure out
the cause.  I will take a look at the failures to see what is going on.

Anyway, just wanted to let you know what I am seeing on PowerPC. 

                                Carl 

On Fri, 2022-08-12 at 10:33 +0100, Luis Machado via Gdb-patches wrote:
> On 8/11/22 12:58, Tom de Vries wrote:
> > Hi,
> > 
> > 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.
> > 
> > Any comments?
> > 
> > Thanks,
> > - Tom
> > 
> > [gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
> > 
> > ---
> >   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-15 16:02 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-11 11:58 Tom de Vries
2022-08-12  9:33 ` Luis Machado
2022-08-15 16:01   ` Carl Love [this message]
2022-08-15 16:54     ` Carl Love
2022-08-15 19:12       ` will schmidt
2022-08-15 19:31         ` Thiago Jung Bauermann
2022-08-15 21:33           ` will schmidt
2022-08-16  7:43         ` Luis Machado
2022-08-16 16:00           ` will schmidt
2022-08-17 12:01       ` Ulrich Weigand
2022-09-01 14:40         ` Tom de Vries
2022-09-01 14:16       ` Tom de Vries

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=923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com \
    --to=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=luis.machado@arm.com \
    --cc=tdevries@suse.de \
    /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).