Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Carl Love via Gdb-patches <gdb-patches@sourceware.org>
To: Luis Machado <luis.machado@arm.com>,
	Tom de Vries <tdevries@suse.de>,
	gdb-patches@sourceware.org,
	Ulrich Weigand <Ulrich.Weigand@de.ibm.com>
Subject: Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp
Date: Mon, 15 Aug 2022 09:54:46 -0700	[thread overview]
Message-ID: <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com> (raw)
In-Reply-To: <923f93e01d32d4515014e983502c7c083c46a83d.camel@us.ibm.com>

Tom:

OK, I took a look at how the test used to work and how it is now
working and I see what the issue is. 

PowerPC has two entry points, local and global.  The test used to set
the breakpoint for the function at the local entry point.  With your
changes, the breakpoint is now being set at the global breakpoint which
is before the local breakpoint.  The function is actually entered at
the local breakpoint thus gdb never "sees" the breakpoint that was set.
Specfically, here is the objdump for the test:

00000000100006e0 <compdir_missing__ldir_missing__file_basename>:
    100006e0:   02 10 40 3c     lis     r2,4098                      <- Global entry point
    100006e4:   00 7f 42 38     addi    r2,r2,32512
    100006e8:   f8 ff e1 fb     std     r31,-8(r1)
    100006ec:   d1 ff 21 f8     stdu    r1,-48(r1)
    100006f0:   78 0b 3f 7c     mr      r31,r1
    100006f4:   00 00 00 60     nop                                  <- Local entry point
    100006f8:   28 81 22 39     addi    r9,r2,-32472
    100006fc:   00 00 29 81     lwz     r9,0(r9)
    10000700:   01 00 49 39     addi    r10,r9,1
    10000704:   00 00 00 60     nop
    10000708:   28 81 22 39     addi    r9,r2,-32472
    1000070c:   00 00 49 91     stw     r10,0(r9)
    10000710:   30 00 3f 38     addi    r1,r31,48
    10000714:   f8 ff e1 eb     ld      r31,-8(r1)
    10000718:   20 00 80 4e     blr

When I look at the output before the patch, we see:

   Breakpoint 2, 0x00000000100006f4 in compdir_missing__ldir_missing__file_basename () at tmp-dw2-dir-file-name.c:999

   (gdb) PASS: gdb.dwarf2/dw2-dir-file-name.exp: compdir_missing__ldir_missing__file_basename: continue to breakpoint: compdir_missing__ldir_missing__file_basename
   set filename-display absolute


Note the breakpoint 2 address is 0x00000000100006f4 which is on the
NOP.  Instructions at addresses 0x100006e0 to 100006f0 are part of the
code when the function is called via the global entry point.  So
previously, the breakpoint was set at local entry point.

With the patch, we now see:

   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)

Now we note that the breakpoint 2 is set at 0x100006e0 which is the
global entry point.  

It looks to me that we need to make sure we set the breakpoint at the
local address.  

Off hand, I am not sure how to get your changes to "proc
gdb_continue_to_breakpoint" to select the local entry point not the
global entry point.  Perhaps Ulrich has some ideas???

                     Carl Love

 
On Mon, 2022-08-15 at 09:01 -0700, Carl Love wrote:

> 
> 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) "                          <-NEED TO FIX TO ALWAYS GIVE local entry point for POWERPC ??                                                                  
> > > +    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:55 UTC|newest]

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

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=6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com \
    --to=gdb-patches@sourceware.org \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --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