Re: [PATCH][gdb/testsuite] Fix gdb.dwarf2/dw2-dir-file-name.exp

[Luis Machado <luis.machado@arm.com>]

On 8/15/22 20:12, will schmidt wrote:
> On Mon, 2022-08-15 at 09:54 -0700, Carl Love 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???
> 
> 
>  From a glance that the patch that updated dw2-dir-file-name.exp;
> ( commit cd919f5533cc8aa495acd75a6f059e5fcf2e6af9 )
> the change there was effectively
> 
> -       gdb_breakpoint $func
> +       gdb_breakpoint *$func
> 
> with assorted regexp changes to match.
> 
> The patch description goes into detail, but I interpret the gist of it
> as avoiding the aarch64 architecture prologue skipper, since that
> prologue skipper does something wrong, with entanglements in the line
> table info.

Though the aarch64 prologue skipper is indeed mistaken here, Tom's patch only
makes the test less reliant on whatever prologue skippers do and instead just
got for a breakpoint straight at the entry point.

It is a void function with void return type, so no much going on. Maybe it needs
to be adapted somewhat to the PowerPC case?


> 
> The powerpc prologue skipper (wherever it is) was presumably handling
> the local/global entry points properly.  Since the test now species a
> specific address (*$func), the prologue skipper is no longer involved.

How does powerpc handle a breakpoint at a particular address?

> 
> The patch should probably be reverted, but I defer to others if I've
> misunderstood part of this issue..
> 
> Thanks
> -Will
> 
> 
> 
> 
> 
> 
> 
> 
>>
>>                       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 $"
>>>>> {
>