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

[Tom de Vries <tdevries@suse.de>]

On 9/12/22 12:20, Luis Machado wrote:
> On 9/1/22 15:09, Tom de Vries via Gdb-patches wrote:
>> In commit cd919f5533c ("[gdb/testsuite] Fix
>> gdb.dwarf2/dw2-dir-file-name.exp"), I made 
>> gdb.dwarf2/dw2-dir-file-name.exp
>> independent of prologue analyzers, using this change:
>> ...
>> -       gdb_breakpoint $func
>> +       gdb_breakpoint *$func
>> ...
>>
>> That however caused a regression on ppc64le.  For PowerPC, as 
>> described in the
>> ELFv2 ABI, a function can have a global and local entry point.
>>
>> Setting a breakpoint on *$func effectively creates a breakpoint for 
>> the global
>> entry point, so if the function is entered through the local entry 
>> point, the
>> breakpoint doesn't trigger.
>>
>> Fix this by reverting commit cd919f5533c, and setting the breakpoint on
>> ${func}_label instead.
>>
>> Tested on x86_64-linux and ppc64le-linux.
>> ---
>>   gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp | 8 ++++----
>>   gdb/testsuite/lib/gdb.exp                      | 7 +------
>>   2 files changed, 5 insertions(+), 10 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp 
>> b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>> index 08b5c645fa2..053f7229537 100644
>> --- a/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>> +++ b/gdb/testsuite/gdb.dwarf2/dw2-dir-file-name.exp
>> @@ -450,20 +450,20 @@ proc test { func compdir filename } {
>>           error "not absolute"
>>       }
>> -    gdb_breakpoint *$func
>> +    gdb_breakpoint ${func}_label
>>       gdb_continue_to_breakpoint $func "$func \\(\\) at .*"
>>       gdb_test_no_output "set filename-display absolute"
>>       verbose -log "expect: ${absolute}"
>> -    gdb_test "frame" "#0  $func \\(\\) at [string_to_regexp 
>> ${absolute}]:999" "absolute"
>> +    gdb_test "frame" " in $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" "#0  $func \\(\\) at [string_to_regexp [file 
>> tail $filename]]:999" "basename"
>> +    gdb_test "frame" " in $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" "#0  $func \\(\\) at [string_to_regexp 
>> $filename]:999" "relative"
>> +    gdb_test "frame" " in $func \\(\\) at [string_to_regexp 
>> $filename]:999" "relative"
>>       }
>>   }
>> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
>> index 17523f82996..2f1147159ad 100644
>> --- a/gdb/testsuite/lib/gdb.exp
>> +++ b/gdb/testsuite/lib/gdb.exp
>> @@ -787,14 +787,9 @@ 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) 
>> .*$re_at_in$location_pattern\r\n$gdb_prompt $" {
>> +    -re "(?:Breakpoint|Temporary breakpoint) .* (at|in) 
>> $location_pattern\r\n$gdb_prompt $" {
>>           pass $full_name
>>       }
>>       -re "\[\r\n\]*(?:$kfail_pattern)\[\r\n\]+$gdb_prompt $" {
> 
> Looks like this makes the testsuite go from PASS to FAIL for aarch64. 
> Are we still stopping in the first instruction and ignoring prologues?

No, we're stopping at the correct instruction, but whether the 
breakpoint is printed with or without instruction address is dependent 
on whether there is a prologue or not, which is an artefact of having a 
rudimentary line table.

I've proposed a fix here ( 
https://sourceware.org/pipermail/gdb-patches/2022-September/191829.html 
), which adds an extra entry in the line table, such that we'll always 
print without instruction address.

Thanks,
- Tom