Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org>
To: Carl Love <cel@us.ibm.com>, Luis Machado <luis.machado@arm.com>,
	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: Thu, 1 Sep 2022 16:16:09 +0200	[thread overview]
Message-ID: <42d8db2c-4cf9-b37e-0ec1-39f4fe1302ef@suse.de> (raw)
In-Reply-To: <6a7bdae3c17ffddd49843215537b9d480f85b2cf.camel@us.ibm.com>

On 8/15/22 18:54, Carl Love via Gdb-patches wrote:
> 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???
> 

Hi Carl,

thanks for reporting this, and the analysis.

I've submitted a patch to fix this here ( 
https://sourceware.org/pipermail/gdb-patches/2022-September/191647.html ).

Thanks,
- Tom

>                       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 $"
>>>> {
> 

      parent reply	other threads:[~2022-09-01 14:16 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
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 [this message]

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=42d8db2c-4cf9-b37e-0ec1-39f4fe1302ef@suse.de \
    --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