[pushed,gdb/testsuite] Use maint ignore-probes in gdb.base/longjmp.exp

  Test-case gdb.base/longjmp.exp handles both the case that there is a libc
longjmp probe, and the case that there isn't.

However, it only tests one of the two cases.

Use maint ignore-probes to test both cases, if possible.

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.base/longjmp.exp | 295 +++++++++++++++--------------
 1 file changed, 157 insertions(+), 138 deletions(-)


base-commit: 0ab9328277ce12014ce05ff139eba7a6230516fd
  

Hi Tom,

Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:

FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)

Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.

This part in particular seems a bit off:

(gdb) break 63
No line 63 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)

On 2/8/23 12:46, Tom de Vries via Gdb-patches wrote:
> Test-case gdb.base/longjmp.exp handles both the case that there is a libc
> longjmp probe, and the case that there isn't.
> 
> However, it only tests one of the two cases.
> 
> Use maint ignore-probes to test both cases, if possible.
> 
> Tested on x86_64-linux.
> ---
>   gdb/testsuite/gdb.base/longjmp.exp | 295 +++++++++++++++--------------
>   1 file changed, 157 insertions(+), 138 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.base/longjmp.exp b/gdb/testsuite/gdb.base/longjmp.exp
> index 27a60bc4502..96d9c1c8059 100644
> --- a/gdb/testsuite/gdb.base/longjmp.exp
> +++ b/gdb/testsuite/gdb.base/longjmp.exp
> @@ -25,181 +25,200 @@ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {deb
>        return -1
>   }
>   
> -clean_restart ${binfile}
> +proc do_test { with_probes } {
> +    clean_restart ${::binfile}
>   
> -if {![runto_main]} {
> -   return 0
> -}
> +    if { !$with_probes } {
> +	gdb_test "maint ignore-probes libc ^longjmp$"
> +    }
>   
> -# With a libc with probes, all tests should pass.
> -#
> -# Without probes, we can still set a break on longjmp, but getting the longjmp
> -# target may not work, in the following cases:
> -# - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
> -# - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on amd64 if
> -#   tdep->jb_pc_offset == -1.
> -# - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc with
> -#   pointer mangling ( https://sourceware.org/glibc/wiki/PointerEncryption )
> -#   then we retrieve a mangled longjmp target that needs to be demangled.
> -#   For instance on amd64 with target board unix/-m32.
> -#
> -# Pointer demangling is currently not implemented for any target.
> -# For the amd64 case, this would require copying for instance this:
> -#   48 c1 ca 11             ror    $0x11,%rdx
> -#   64 48 33 14 25 30 00    xor    %fs:0x30,%rdx
> -# into a scratch space, save the register set, set %rdx to the mangled
> -# longjmp target, displaced-step through the two insn and read the
> -# demangled longjmp target from %rdx, and restore the register set.
> -#
> -# The failure mode in the first two cases is that the next degrades into a
> -# continue.  The failure mode in the latter case is a failure to set a
> -# breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
> -#
> -# We detect the different failure modes and kfail these.
> +    if {![runto_main]} {
> +	return 0
> +    }
>   
> -set have_longjmp_probe 0
> -gdb_test_multiple "info probes stap libc ^longjmp$" "" {
> -    -re -wrap "No probes matched\\." {
> -	pass $gdb_test_name
> +    # With a libc with probes, all tests should pass.
> +    #
> +    # Without probes, we can still set a break on longjmp, but getting the longjmp
> +    # target may not work, in the following cases:
> +    # - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
> +    # - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on amd64 if
> +    #   tdep->jb_pc_offset == -1.
> +    # - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc with
> +    #   pointer mangling ( https://sourceware.org/glibc/wiki/PointerEncryption )
> +    #   then we retrieve a mangled longjmp target that needs to be demangled.
> +    #   For instance on amd64 with target board unix/-m32.
> +    #
> +    # Pointer demangling is currently not implemented for any target.
> +    # For the amd64 case, this would require copying for instance this:
> +    #   48 c1 ca 11             ror    $0x11,%rdx
> +    #   64 48 33 14 25 30 00    xor    %fs:0x30,%rdx
> +    # into a scratch space, save the register set, set %rdx to the mangled
> +    # longjmp target, displaced-step through the two insn and read the
> +    # demangled longjmp target from %rdx, and restore the register set.
> +    #
> +    # The failure mode in the first two cases is that the next degrades into a
> +    # continue.  The failure mode in the latter case is a failure to set a
> +    # breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
> +    #
> +    # We detect the different failure modes and kfail these.
> +
> +    set have_longjmp_probe 0
> +    gdb_test_multiple "info probes stap libc ^longjmp$" "" {
> +	-re -wrap "No probes matched\\." {
> +	    pass $gdb_test_name
> +	}
> +	-re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
> +	    pass $gdb_test_name
> +	    set have_longjmp_probe 1
> +	}
>       }
> -    -re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
> -	pass $gdb_test_name
> -	set have_longjmp_probe 1
> +
> +    if { $with_probes } {
> +	if { !$have_longjmp_probe } {
> +	    unsupported "longjmp probe required"
> +	    return
> +	}
> +    } else {
> +	gdb_assert { !$have_longjmp_probe }
>       }
> -}
>   
> -set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
> -set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
> +    set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
> +    set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
>   
> -set bp_start_test_1 [gdb_get_line_number "patt1"]
> -set bp_start_test_2 [gdb_get_line_number "patt2"]
> -set bp_start_test_3 [gdb_get_line_number "patt3"]
> +    set bp_start_test_1 [gdb_get_line_number "patt1"]
> +    set bp_start_test_2 [gdb_get_line_number "patt2"]
> +    set bp_start_test_3 [gdb_get_line_number "patt3"]
>   
> -set re_cannot_insert_bp \
> -    [multi_line \
> -	 "Warning:" \
> -	 "Cannot insert breakpoint $decimal\\." \
> -	 "Cannot access memory at address $hex"]
> +    set re_cannot_insert_bp \
> +	[multi_line \
> +	     "Warning:" \
> +	     "Cannot insert breakpoint $::decimal\\." \
> +	     "Cannot access memory at address $::hex"]
>   
> -#
> -# Pattern 1 - simple longjmp.
> -#
> +    #
> +    # Pattern 1 - simple longjmp.
> +    #
>   
> -with_test_prefix "pattern 1" {
> +    with_test_prefix "pattern 1" {
>   
> -    with_test_prefix setup {
> -	delete_breakpoints
> +	with_test_prefix setup {
> +	    delete_breakpoints
>   
> -	gdb_test "break $bp_start_test_1" \
> -	    "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_1.*" \
> -	    "breakpoint at pattern start"
> -	gdb_test "continue" "patt1.*" "continue to breakpoint at pattern start"
> +	    gdb_test "break $bp_start_test_1" \
> +		"Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_1.*" \
> +		"breakpoint at pattern start"
> +	    gdb_test "continue" "patt1.*" "continue to breakpoint at pattern start"
>   
> -	# set safe-net break
> -	gdb_test "break $bp_miss_step_1" \
> -	    "Breakpoint.*at.* file .*$srcfile, line.*$bp_miss_step_1.*" \
> -	    "breakpoint at safety net"
> -    }
> +	    # set safe-net break
> +	    gdb_test "break $bp_miss_step_1" \
> +		"Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_1.*" \
> +		"breakpoint at safety net"
> +	}
>   
> -    gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
> -    gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
> +	gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
> +	gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
>   
> -    set msg "next over longjmp"
> -    gdb_test_multiple "next" $msg {
> -	-re ".*patt1.*$gdb_prompt $" {
> -	    pass $msg
> -	    gdb_test "next" "resumes\\+\\+.*" "next into else block"
> -	    gdb_test "next" "miss_step_1.*" "next into safety net"
> -	}
> -	-re "miss_step_1.*$gdb_prompt $" {
> -	    if { $have_longjmp_probe } {
> -		fail $gdb_test_name
> -	    } else {
> -		kfail $gdb_test_name "gdb/26967"
> +	set msg "next over longjmp"
> +	gdb_test_multiple "next" $msg {
> +	    -re ".*patt1.*$::gdb_prompt $" {
> +		pass $msg
> +		gdb_test "next" "resumes\\+\\+.*" "next into else block"
> +		gdb_test "next" "miss_step_1.*" "next into safety net"
>   	    }
> -	}
> -	-re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
> -	    if { $have_longjmp_probe } {
> -		fail $gdb_test_name
> -	    } else {
> -		kfail $gdb_test_name "gdb/26967"
> +	    -re "miss_step_1.*$::gdb_prompt $" {
> +		if { $have_longjmp_probe } {
> +		    fail $gdb_test_name
> +		} else {
> +		    kfail $gdb_test_name "gdb/26967"
> +		}
> +	    }
> +	    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
> +		if { $have_longjmp_probe } {
> +		    fail $gdb_test_name
> +		} else {
> +		    kfail $gdb_test_name "gdb/26967"
> +		}
>   	    }
>   	}
>       }
> -}
>   
> -#
> -# Pattern 2 - longjmp from an inner function.
> -#
> +    #
> +    # Pattern 2 - longjmp from an inner function.
> +    #
>   
> -with_test_prefix "pattern 2" {
> +    with_test_prefix "pattern 2" {
>   
> -    with_test_prefix setup {
> -	delete_breakpoints
> +	with_test_prefix setup {
> +	    delete_breakpoints
>   
> -	gdb_test "break $bp_start_test_2" \
> -	    "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_2.*" \
> -	    "breakpoint at pattern start"
> -	gdb_test "continue" "patt2.*" "continue to breakpoint at pattern start"
> +	    gdb_test "break $bp_start_test_2" \
> +		"Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_2.*" \
> +		"breakpoint at pattern start"
> +	    gdb_test "continue" "patt2.*" "continue to breakpoint at pattern start"
>   
> -	# set safe-net break
> -	gdb_test "break $bp_miss_step_2" \
> -	    "Breakpoint.*at.* file .*$srcfile, line.*$bp_miss_step_2.*" \
> -	    "breakpoint at safety net"
> -    }
> +	    # set safe-net break
> +	    gdb_test "break $bp_miss_step_2" \
> +		"Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_2.*" \
> +		"breakpoint at safety net"
> +	}
>   
> -    gdb_test "next" "call_longjmp.*" "next over setjmp"
> +	gdb_test "next" "call_longjmp.*" "next over setjmp"
>   
> -    set msg "next over call_longjmp"
> -    gdb_test_multiple "next" $msg {
> -	-re ".*patt2.*$gdb_prompt $" {
> -	    pass $msg
> +	set msg "next over call_longjmp"
> +	gdb_test_multiple "next" $msg {
> +	    -re ".*patt2.*$::gdb_prompt $" {
> +		pass $msg
>   
> -	    gdb_test "next" "resumes\\+\\+.*" "next into else block"
> -	    gdb_test "next" "miss_step_2.*" "next into safety net"
> -	}
> -	-re "miss_step_2.*$gdb_prompt $" {
> -	    if { $have_longjmp_probe } {
> -		fail $gdb_test_name
> -	    } else {
> -		kfail $gdb_test_name "gdb/26967"
> +		gdb_test "next" "resumes\\+\\+.*" "next into else block"
> +		gdb_test "next" "miss_step_2.*" "next into safety net"
>   	    }
> -	}
> -	-re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
> -	    if { $have_longjmp_probe } {
> -		fail $gdb_test_name
> -	    } else {
> -		kfail $gdb_test_name "gdb/26967"
> +	    -re "miss_step_2.*$::gdb_prompt $" {
> +		if { $have_longjmp_probe } {
> +		    fail $gdb_test_name
> +		} else {
> +		    kfail $gdb_test_name "gdb/26967"
> +		}
> +	    }
> +	    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
> +		if { $have_longjmp_probe } {
> +		    fail $gdb_test_name
> +		} else {
> +		    kfail $gdb_test_name "gdb/26967"
> +		}
>   	    }
>   	}
>       }
> -}
>   
> -#
> -# Pattern 3 - setjmp/longjmp inside stepped-over function.
> -#
> +    #
> +    # Pattern 3 - setjmp/longjmp inside stepped-over function.
> +    #
>   
> -with_test_prefix "pattern 3" {
> +    with_test_prefix "pattern 3" {
>   
> -    with_test_prefix setup {
> -	delete_breakpoints
> +	with_test_prefix setup {
> +	    delete_breakpoints
>   
> -	gdb_test "break $bp_start_test_3" \
> -	    "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_3.*" \
> -	    "breakpoint at pattern start"
> -	gdb_test "continue" "patt3.*" "continue to breakpoint at pattern start"
> -    }
> -
> -    gdb_test_multiple "next" "next over pattern" {
> -	-re -wrap "longjmp caught.*" {
> -	    pass $gdb_test_name
> +	    gdb_test "break $bp_start_test_3" \
> +		"Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_3.*" \
> +		"breakpoint at pattern start"
> +	    gdb_test "continue" "patt3.*" "continue to breakpoint at pattern start"
>   	}
> -	-re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
> -	    if { $have_longjmp_probe } {
> -		fail $gdb_test_name
> -	    } else {
> -		kfail $gdb_test_name "gdb/26967"
> +
> +	gdb_test_multiple "next" "next over pattern" {
> +	    -re -wrap "longjmp caught.*" {
> +		pass $gdb_test_name
> +	    }
> +	    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
> +		if { $have_longjmp_probe } {
> +		    fail $gdb_test_name
> +		} else {
> +		    kfail $gdb_test_name "gdb/26967"
> +		}
>   	    }
>   	}
>       }
>   }
> +
> +foreach_with_prefix with_probes { 0 1 } {
> +    do_test $with_probes
> +}
> 
> base-commit: 0ab9328277ce12014ce05ff139eba7a6230516fd
  

On 2/8/23 14:27, Luis Machado wrote:
> Hi Tom,
> 
> Is the entire test supposed to PASS? I'm seeing the following on my 
> aarch64/Ubuntu 22.04 setup:
> 
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
> call_longjmp (the program is no longer running)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp 
> (the program is no longer running)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint 
> at pattern start (got interactive prompt)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint 
> at safety net (got interactive prompt)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to 
> breakpoint at pattern start (the program exited)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern 
> (the program is no longer running)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint 
> at pattern start (got interactive prompt)
> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to 
> breakpoint at pattern start (the program is no longer running)
> 
> Maybe something is genuinely broken for aarch64 though, or I'm missing 
> some packages/debuginfo.

Hi,

I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.

> 
> This part in particular seems a bit off:
> 
> (gdb) break 63
> No line 63 in the current file.
> Make breakpoint pending on future shared library load? (y or [n]) n
> (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
> breakpoint at pattern start (got interactive prompt)
> 

I'd focus on the first FAIL.  Why is the safety net breakpoint not 
triggering?

Thanks,
- Tom

> On 2/8/23 12:46, Tom de Vries via Gdb-patches wrote:
>> Test-case gdb.base/longjmp.exp handles both the case that there is a libc
>> longjmp probe, and the case that there isn't.
>>
>> However, it only tests one of the two cases.
>>
>> Use maint ignore-probes to test both cases, if possible.
>>
>> Tested on x86_64-linux.
>> ---
>>   gdb/testsuite/gdb.base/longjmp.exp | 295 +++++++++++++++--------------
>>   1 file changed, 157 insertions(+), 138 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/longjmp.exp 
>> b/gdb/testsuite/gdb.base/longjmp.exp
>> index 27a60bc4502..96d9c1c8059 100644
>> --- a/gdb/testsuite/gdb.base/longjmp.exp
>> +++ b/gdb/testsuite/gdb.base/longjmp.exp
>> @@ -25,181 +25,200 @@ if  { [gdb_compile 
>> "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {deb
>>        return -1
>>   }
>> -clean_restart ${binfile}
>> +proc do_test { with_probes } {
>> +    clean_restart ${::binfile}
>> -if {![runto_main]} {
>> -   return 0
>> -}
>> +    if { !$with_probes } {
>> +    gdb_test "maint ignore-probes libc ^longjmp$"
>> +    }
>> -# With a libc with probes, all tests should pass.
>> -#
>> -# Without probes, we can still set a break on longjmp, but getting 
>> the longjmp
>> -# target may not work, in the following cases:
>> -# - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
>> -# - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on amd64 if
>> -#   tdep->jb_pc_offset == -1.
>> -# - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc with
>> -#   pointer mangling ( 
>> https://sourceware.org/glibc/wiki/PointerEncryption )
>> -#   then we retrieve a mangled longjmp target that needs to be 
>> demangled.
>> -#   For instance on amd64 with target board unix/-m32.
>> -#
>> -# Pointer demangling is currently not implemented for any target.
>> -# For the amd64 case, this would require copying for instance this:
>> -#   48 c1 ca 11             ror    $0x11,%rdx
>> -#   64 48 33 14 25 30 00    xor    %fs:0x30,%rdx
>> -# into a scratch space, save the register set, set %rdx to the mangled
>> -# longjmp target, displaced-step through the two insn and read the
>> -# demangled longjmp target from %rdx, and restore the register set.
>> -#
>> -# The failure mode in the first two cases is that the next degrades 
>> into a
>> -# continue.  The failure mode in the latter case is a failure to set a
>> -# breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
>> -#
>> -# We detect the different failure modes and kfail these.
>> +    if {![runto_main]} {
>> +    return 0
>> +    }
>> -set have_longjmp_probe 0
>> -gdb_test_multiple "info probes stap libc ^longjmp$" "" {
>> -    -re -wrap "No probes matched\\." {
>> -    pass $gdb_test_name
>> +    # With a libc with probes, all tests should pass.
>> +    #
>> +    # Without probes, we can still set a break on longjmp, but 
>> getting the longjmp
>> +    # target may not work, in the following cases:
>> +    # - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
>> +    # - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on 
>> amd64 if
>> +    #   tdep->jb_pc_offset == -1.
>> +    # - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc 
>> with
>> +    #   pointer mangling ( 
>> https://sourceware.org/glibc/wiki/PointerEncryption )
>> +    #   then we retrieve a mangled longjmp target that needs to be 
>> demangled.
>> +    #   For instance on amd64 with target board unix/-m32.
>> +    #
>> +    # Pointer demangling is currently not implemented for any target.
>> +    # For the amd64 case, this would require copying for instance this:
>> +    #   48 c1 ca 11             ror    $0x11,%rdx
>> +    #   64 48 33 14 25 30 00    xor    %fs:0x30,%rdx
>> +    # into a scratch space, save the register set, set %rdx to the 
>> mangled
>> +    # longjmp target, displaced-step through the two insn and read the
>> +    # demangled longjmp target from %rdx, and restore the register set.
>> +    #
>> +    # The failure mode in the first two cases is that the next 
>> degrades into a
>> +    # continue.  The failure mode in the latter case is a failure to 
>> set a
>> +    # breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
>> +    #
>> +    # We detect the different failure modes and kfail these.
>> +
>> +    set have_longjmp_probe 0
>> +    gdb_test_multiple "info probes stap libc ^longjmp$" "" {
>> +    -re -wrap "No probes matched\\." {
>> +        pass $gdb_test_name
>> +    }
>> +    -re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
>> +        pass $gdb_test_name
>> +        set have_longjmp_probe 1
>> +    }
>>       }
>> -    -re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
>> -    pass $gdb_test_name
>> -    set have_longjmp_probe 1
>> +
>> +    if { $with_probes } {
>> +    if { !$have_longjmp_probe } {
>> +        unsupported "longjmp probe required"
>> +        return
>> +    }
>> +    } else {
>> +    gdb_assert { !$have_longjmp_probe }
>>       }
>> -}
>> -set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
>> -set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
>> +    set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
>> +    set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
>> -set bp_start_test_1 [gdb_get_line_number "patt1"]
>> -set bp_start_test_2 [gdb_get_line_number "patt2"]
>> -set bp_start_test_3 [gdb_get_line_number "patt3"]
>> +    set bp_start_test_1 [gdb_get_line_number "patt1"]
>> +    set bp_start_test_2 [gdb_get_line_number "patt2"]
>> +    set bp_start_test_3 [gdb_get_line_number "patt3"]
>> -set re_cannot_insert_bp \
>> -    [multi_line \
>> -     "Warning:" \
>> -     "Cannot insert breakpoint $decimal\\." \
>> -     "Cannot access memory at address $hex"]
>> +    set re_cannot_insert_bp \
>> +    [multi_line \
>> +         "Warning:" \
>> +         "Cannot insert breakpoint $::decimal\\." \
>> +         "Cannot access memory at address $::hex"]
>> -#
>> -# Pattern 1 - simple longjmp.
>> -#
>> +    #
>> +    # Pattern 1 - simple longjmp.
>> +    #
>> -with_test_prefix "pattern 1" {
>> +    with_test_prefix "pattern 1" {
>> -    with_test_prefix setup {
>> -    delete_breakpoints
>> +    with_test_prefix setup {
>> +        delete_breakpoints
>> -    gdb_test "break $bp_start_test_1" \
>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_1.*" \
>> -        "breakpoint at pattern start"
>> -    gdb_test "continue" "patt1.*" "continue to breakpoint at pattern 
>> start"
>> +        gdb_test "break $bp_start_test_1" \
>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_1.*" \
>> +        "breakpoint at pattern start"
>> +        gdb_test "continue" "patt1.*" "continue to breakpoint at 
>> pattern start"
>> -    # set safe-net break
>> -    gdb_test "break $bp_miss_step_1" \
>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_miss_step_1.*" \
>> -        "breakpoint at safety net"
>> -    }
>> +        # set safe-net break
>> +        gdb_test "break $bp_miss_step_1" \
>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_1.*" \
>> +        "breakpoint at safety net"
>> +    }
>> -    gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
>> -    gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
>> +    gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
>> +    gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
>> -    set msg "next over longjmp"
>> -    gdb_test_multiple "next" $msg {
>> -    -re ".*patt1.*$gdb_prompt $" {
>> -        pass $msg
>> -        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>> -        gdb_test "next" "miss_step_1.*" "next into safety net"
>> -    }
>> -    -re "miss_step_1.*$gdb_prompt $" {
>> -        if { $have_longjmp_probe } {
>> -        fail $gdb_test_name
>> -        } else {
>> -        kfail $gdb_test_name "gdb/26967"
>> +    set msg "next over longjmp"
>> +    gdb_test_multiple "next" $msg {
>> +        -re ".*patt1.*$::gdb_prompt $" {
>> +        pass $msg
>> +        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>> +        gdb_test "next" "miss_step_1.*" "next into safety net"
>>           }
>> -    }
>> -    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>> -        if { $have_longjmp_probe } {
>> -        fail $gdb_test_name
>> -        } else {
>> -        kfail $gdb_test_name "gdb/26967"
>> +        -re "miss_step_1.*$::gdb_prompt $" {
>> +        if { $have_longjmp_probe } {
>> +            fail $gdb_test_name
>> +        } else {
>> +            kfail $gdb_test_name "gdb/26967"
>> +        }
>> +        }
>> +        -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>> +        if { $have_longjmp_probe } {
>> +            fail $gdb_test_name
>> +        } else {
>> +            kfail $gdb_test_name "gdb/26967"
>> +        }
>>           }
>>       }
>>       }
>> -}
>> -#
>> -# Pattern 2 - longjmp from an inner function.
>> -#
>> +    #
>> +    # Pattern 2 - longjmp from an inner function.
>> +    #
>> -with_test_prefix "pattern 2" {
>> +    with_test_prefix "pattern 2" {
>> -    with_test_prefix setup {
>> -    delete_breakpoints
>> +    with_test_prefix setup {
>> +        delete_breakpoints
>> -    gdb_test "break $bp_start_test_2" \
>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_2.*" \
>> -        "breakpoint at pattern start"
>> -    gdb_test "continue" "patt2.*" "continue to breakpoint at pattern 
>> start"
>> +        gdb_test "break $bp_start_test_2" \
>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_2.*" \
>> +        "breakpoint at pattern start"
>> +        gdb_test "continue" "patt2.*" "continue to breakpoint at 
>> pattern start"
>> -    # set safe-net break
>> -    gdb_test "break $bp_miss_step_2" \
>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_miss_step_2.*" \
>> -        "breakpoint at safety net"
>> -    }
>> +        # set safe-net break
>> +        gdb_test "break $bp_miss_step_2" \
>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_2.*" \
>> +        "breakpoint at safety net"
>> +    }
>> -    gdb_test "next" "call_longjmp.*" "next over setjmp"
>> +    gdb_test "next" "call_longjmp.*" "next over setjmp"
>> -    set msg "next over call_longjmp"
>> -    gdb_test_multiple "next" $msg {
>> -    -re ".*patt2.*$gdb_prompt $" {
>> -        pass $msg
>> +    set msg "next over call_longjmp"
>> +    gdb_test_multiple "next" $msg {
>> +        -re ".*patt2.*$::gdb_prompt $" {
>> +        pass $msg
>> -        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>> -        gdb_test "next" "miss_step_2.*" "next into safety net"
>> -    }
>> -    -re "miss_step_2.*$gdb_prompt $" {
>> -        if { $have_longjmp_probe } {
>> -        fail $gdb_test_name
>> -        } else {
>> -        kfail $gdb_test_name "gdb/26967"
>> +        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>> +        gdb_test "next" "miss_step_2.*" "next into safety net"
>>           }
>> -    }
>> -    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>> -        if { $have_longjmp_probe } {
>> -        fail $gdb_test_name
>> -        } else {
>> -        kfail $gdb_test_name "gdb/26967"
>> +        -re "miss_step_2.*$::gdb_prompt $" {
>> +        if { $have_longjmp_probe } {
>> +            fail $gdb_test_name
>> +        } else {
>> +            kfail $gdb_test_name "gdb/26967"
>> +        }
>> +        }
>> +        -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>> +        if { $have_longjmp_probe } {
>> +            fail $gdb_test_name
>> +        } else {
>> +            kfail $gdb_test_name "gdb/26967"
>> +        }
>>           }
>>       }
>>       }
>> -}
>> -#
>> -# Pattern 3 - setjmp/longjmp inside stepped-over function.
>> -#
>> +    #
>> +    # Pattern 3 - setjmp/longjmp inside stepped-over function.
>> +    #
>> -with_test_prefix "pattern 3" {
>> +    with_test_prefix "pattern 3" {
>> -    with_test_prefix setup {
>> -    delete_breakpoints
>> +    with_test_prefix setup {
>> +        delete_breakpoints
>> -    gdb_test "break $bp_start_test_3" \
>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_3.*" \
>> -        "breakpoint at pattern start"
>> -    gdb_test "continue" "patt3.*" "continue to breakpoint at pattern 
>> start"
>> -    }
>> -
>> -    gdb_test_multiple "next" "next over pattern" {
>> -    -re -wrap "longjmp caught.*" {
>> -        pass $gdb_test_name
>> +        gdb_test "break $bp_start_test_3" \
>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_3.*" \
>> +        "breakpoint at pattern start"
>> +        gdb_test "continue" "patt3.*" "continue to breakpoint at 
>> pattern start"
>>       }
>> -    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>> -        if { $have_longjmp_probe } {
>> -        fail $gdb_test_name
>> -        } else {
>> -        kfail $gdb_test_name "gdb/26967"
>> +
>> +    gdb_test_multiple "next" "next over pattern" {
>> +        -re -wrap "longjmp caught.*" {
>> +        pass $gdb_test_name
>> +        }
>> +        -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>> +        if { $have_longjmp_probe } {
>> +            fail $gdb_test_name
>> +        } else {
>> +            kfail $gdb_test_name "gdb/26967"
>> +        }
>>           }
>>       }
>>       }
>>   }
>> +
>> +foreach_with_prefix with_probes { 0 1 } {
>> +    do_test $with_probes
>> +}
>>
>> base-commit: 0ab9328277ce12014ce05ff139eba7a6230516fd
>
  

On 2/8/23 14:48, Tom de Vries wrote:
> On 2/8/23 14:27, Luis Machado wrote:
>> Hi Tom,
>>
>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>
>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
> 
> Hi,
> 
> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
> 

Alright. That's good to know.

>>
>> This part in particular seems a bit off:
>>
>> (gdb) break 63
>> No line 63 in the current file.
>> Make breakpoint pending on future shared library load? (y or [n]) n
>> (gdb) FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>
> 
> I'd focus on the first FAIL.  Why is the safety net breakpoint not triggering?

Yeah, it seems a bit fishy. I'll take a look. Thanks!

> 
> Thanks,
> - Tom
> 
>> On 2/8/23 12:46, Tom de Vries via Gdb-patches wrote:
>>> Test-case gdb.base/longjmp.exp handles both the case that there is a libc
>>> longjmp probe, and the case that there isn't.
>>>
>>> However, it only tests one of the two cases.
>>>
>>> Use maint ignore-probes to test both cases, if possible.
>>>
>>> Tested on x86_64-linux.
>>> ---
>>>   gdb/testsuite/gdb.base/longjmp.exp | 295 +++++++++++++++--------------
>>>   1 file changed, 157 insertions(+), 138 deletions(-)
>>>
>>> diff --git a/gdb/testsuite/gdb.base/longjmp.exp b/gdb/testsuite/gdb.base/longjmp.exp
>>> index 27a60bc4502..96d9c1c8059 100644
>>> --- a/gdb/testsuite/gdb.base/longjmp.exp
>>> +++ b/gdb/testsuite/gdb.base/longjmp.exp
>>> @@ -25,181 +25,200 @@ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {deb
>>>        return -1
>>>   }
>>> -clean_restart ${binfile}
>>> +proc do_test { with_probes } {
>>> +    clean_restart ${::binfile}
>>> -if {![runto_main]} {
>>> -   return 0
>>> -}
>>> +    if { !$with_probes } {
>>> +    gdb_test "maint ignore-probes libc ^longjmp$"
>>> +    }
>>> -# With a libc with probes, all tests should pass.
>>> -#
>>> -# Without probes, we can still set a break on longjmp, but getting the longjmp
>>> -# target may not work, in the following cases:
>>> -# - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
>>> -# - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on amd64 if
>>> -#   tdep->jb_pc_offset == -1.
>>> -# - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc with
>>> -#   pointer mangling ( https://sourceware.org/glibc/wiki/PointerEncryption )
>>> -#   then we retrieve a mangled longjmp target that needs to be demangled.
>>> -#   For instance on amd64 with target board unix/-m32.
>>> -#
>>> -# Pointer demangling is currently not implemented for any target.
>>> -# For the amd64 case, this would require copying for instance this:
>>> -#   48 c1 ca 11             ror    $0x11,%rdx
>>> -#   64 48 33 14 25 30 00    xor    %fs:0x30,%rdx
>>> -# into a scratch space, save the register set, set %rdx to the mangled
>>> -# longjmp target, displaced-step through the two insn and read the
>>> -# demangled longjmp target from %rdx, and restore the register set.
>>> -#
>>> -# The failure mode in the first two cases is that the next degrades into a
>>> -# continue.  The failure mode in the latter case is a failure to set a
>>> -# breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
>>> -#
>>> -# We detect the different failure modes and kfail these.
>>> +    if {![runto_main]} {
>>> +    return 0
>>> +    }
>>> -set have_longjmp_probe 0
>>> -gdb_test_multiple "info probes stap libc ^longjmp$" "" {
>>> -    -re -wrap "No probes matched\\." {
>>> -    pass $gdb_test_name
>>> +    # With a libc with probes, all tests should pass.
>>> +    #
>>> +    # Without probes, we can still set a break on longjmp, but getting the longjmp
>>> +    # target may not work, in the following cases:
>>> +    # - gdbarch_get_longjmp_target_p (gdbarch) == 0: not implemented.
>>> +    # - gdbarch_get_longjmp_target (gdbarch) == 0: for instance on amd64 if
>>> +    #   tdep->jb_pc_offset == -1.
>>> +    # - gdbarch_get_longjmp_target (gdbarch) != 0: if we have a glibc with
>>> +    #   pointer mangling ( https://sourceware.org/glibc/wiki/PointerEncryption )
>>> +    #   then we retrieve a mangled longjmp target that needs to be demangled.
>>> +    #   For instance on amd64 with target board unix/-m32.
>>> +    #
>>> +    # Pointer demangling is currently not implemented for any target.
>>> +    # For the amd64 case, this would require copying for instance this:
>>> +    #   48 c1 ca 11             ror    $0x11,%rdx
>>> +    #   64 48 33 14 25 30 00    xor    %fs:0x30,%rdx
>>> +    # into a scratch space, save the register set, set %rdx to the mangled
>>> +    # longjmp target, displaced-step through the two insn and read the
>>> +    # demangled longjmp target from %rdx, and restore the register set.
>>> +    #
>>> +    # The failure mode in the first two cases is that the next degrades into a
>>> +    # continue.  The failure mode in the latter case is a failure to set a
>>> +    # breakpoint (matched by re_cannot_insert_bp) and a stop in longjmp.
>>> +    #
>>> +    # We detect the different failure modes and kfail these.
>>> +
>>> +    set have_longjmp_probe 0
>>> +    gdb_test_multiple "info probes stap libc ^longjmp$" "" {
>>> +    -re -wrap "No probes matched\\." {
>>> +        pass $gdb_test_name
>>> +    }
>>> +    -re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
>>> +        pass $gdb_test_name
>>> +        set have_longjmp_probe 1
>>> +    }
>>>       }
>>> -    -re -wrap "\r\nstap\[ \t\]+libc\[ \t\]+longjmp\[ \t\]+.*" {
>>> -    pass $gdb_test_name
>>> -    set have_longjmp_probe 1
>>> +
>>> +    if { $with_probes } {
>>> +    if { !$have_longjmp_probe } {
>>> +        unsupported "longjmp probe required"
>>> +        return
>>> +    }
>>> +    } else {
>>> +    gdb_assert { !$have_longjmp_probe }
>>>       }
>>> -}
>>> -set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
>>> -set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
>>> +    set bp_miss_step_1 [gdb_get_line_number "miss_step_1"]
>>> +    set bp_miss_step_2 [gdb_get_line_number "miss_step_2"]
>>> -set bp_start_test_1 [gdb_get_line_number "patt1"]
>>> -set bp_start_test_2 [gdb_get_line_number "patt2"]
>>> -set bp_start_test_3 [gdb_get_line_number "patt3"]
>>> +    set bp_start_test_1 [gdb_get_line_number "patt1"]
>>> +    set bp_start_test_2 [gdb_get_line_number "patt2"]
>>> +    set bp_start_test_3 [gdb_get_line_number "patt3"]
>>> -set re_cannot_insert_bp \
>>> -    [multi_line \
>>> -     "Warning:" \
>>> -     "Cannot insert breakpoint $decimal\\." \
>>> -     "Cannot access memory at address $hex"]
>>> +    set re_cannot_insert_bp \
>>> +    [multi_line \
>>> +         "Warning:" \
>>> +         "Cannot insert breakpoint $::decimal\\." \
>>> +         "Cannot access memory at address $::hex"]
>>> -#
>>> -# Pattern 1 - simple longjmp.
>>> -#
>>> +    #
>>> +    # Pattern 1 - simple longjmp.
>>> +    #
>>> -with_test_prefix "pattern 1" {
>>> +    with_test_prefix "pattern 1" {
>>> -    with_test_prefix setup {
>>> -    delete_breakpoints
>>> +    with_test_prefix setup {
>>> +        delete_breakpoints
>>> -    gdb_test "break $bp_start_test_1" \
>>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_1.*" \
>>> -        "breakpoint at pattern start"
>>> -    gdb_test "continue" "patt1.*" "continue to breakpoint at pattern start"
>>> +        gdb_test "break $bp_start_test_1" \
>>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_1.*" \
>>> +        "breakpoint at pattern start"
>>> +        gdb_test "continue" "patt1.*" "continue to breakpoint at pattern start"
>>> -    # set safe-net break
>>> -    gdb_test "break $bp_miss_step_1" \
>>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_miss_step_1.*" \
>>> -        "breakpoint at safety net"
>>> -    }
>>> +        # set safe-net break
>>> +        gdb_test "break $bp_miss_step_1" \
>>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_1.*" \
>>> +        "breakpoint at safety net"
>>> +    }
>>> -    gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
>>> -    gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
>>> +    gdb_test "next" "longjmps\\+\\+;.*" "next over setjmp"
>>> +    gdb_test "next" "longjmp \\(env, 1\\);.*" "next to longjmp"
>>> -    set msg "next over longjmp"
>>> -    gdb_test_multiple "next" $msg {
>>> -    -re ".*patt1.*$gdb_prompt $" {
>>> -        pass $msg
>>> -        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>>> -        gdb_test "next" "miss_step_1.*" "next into safety net"
>>> -    }
>>> -    -re "miss_step_1.*$gdb_prompt $" {
>>> -        if { $have_longjmp_probe } {
>>> -        fail $gdb_test_name
>>> -        } else {
>>> -        kfail $gdb_test_name "gdb/26967"
>>> +    set msg "next over longjmp"
>>> +    gdb_test_multiple "next" $msg {
>>> +        -re ".*patt1.*$::gdb_prompt $" {
>>> +        pass $msg
>>> +        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>>> +        gdb_test "next" "miss_step_1.*" "next into safety net"
>>>           }
>>> -    }
>>> -    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>>> -        if { $have_longjmp_probe } {
>>> -        fail $gdb_test_name
>>> -        } else {
>>> -        kfail $gdb_test_name "gdb/26967"
>>> +        -re "miss_step_1.*$::gdb_prompt $" {
>>> +        if { $have_longjmp_probe } {
>>> +            fail $gdb_test_name
>>> +        } else {
>>> +            kfail $gdb_test_name "gdb/26967"
>>> +        }
>>> +        }
>>> +        -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>>> +        if { $have_longjmp_probe } {
>>> +            fail $gdb_test_name
>>> +        } else {
>>> +            kfail $gdb_test_name "gdb/26967"
>>> +        }
>>>           }
>>>       }
>>>       }
>>> -}
>>> -#
>>> -# Pattern 2 - longjmp from an inner function.
>>> -#
>>> +    #
>>> +    # Pattern 2 - longjmp from an inner function.
>>> +    #
>>> -with_test_prefix "pattern 2" {
>>> +    with_test_prefix "pattern 2" {
>>> -    with_test_prefix setup {
>>> -    delete_breakpoints
>>> +    with_test_prefix setup {
>>> +        delete_breakpoints
>>> -    gdb_test "break $bp_start_test_2" \
>>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_2.*" \
>>> -        "breakpoint at pattern start"
>>> -    gdb_test "continue" "patt2.*" "continue to breakpoint at pattern start"
>>> +        gdb_test "break $bp_start_test_2" \
>>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_2.*" \
>>> +        "breakpoint at pattern start"
>>> +        gdb_test "continue" "patt2.*" "continue to breakpoint at pattern start"
>>> -    # set safe-net break
>>> -    gdb_test "break $bp_miss_step_2" \
>>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_miss_step_2.*" \
>>> -        "breakpoint at safety net"
>>> -    }
>>> +        # set safe-net break
>>> +        gdb_test "break $bp_miss_step_2" \
>>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_miss_step_2.*" \
>>> +        "breakpoint at safety net"
>>> +    }
>>> -    gdb_test "next" "call_longjmp.*" "next over setjmp"
>>> +    gdb_test "next" "call_longjmp.*" "next over setjmp"
>>> -    set msg "next over call_longjmp"
>>> -    gdb_test_multiple "next" $msg {
>>> -    -re ".*patt2.*$gdb_prompt $" {
>>> -        pass $msg
>>> +    set msg "next over call_longjmp"
>>> +    gdb_test_multiple "next" $msg {
>>> +        -re ".*patt2.*$::gdb_prompt $" {
>>> +        pass $msg
>>> -        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>>> -        gdb_test "next" "miss_step_2.*" "next into safety net"
>>> -    }
>>> -    -re "miss_step_2.*$gdb_prompt $" {
>>> -        if { $have_longjmp_probe } {
>>> -        fail $gdb_test_name
>>> -        } else {
>>> -        kfail $gdb_test_name "gdb/26967"
>>> +        gdb_test "next" "resumes\\+\\+.*" "next into else block"
>>> +        gdb_test "next" "miss_step_2.*" "next into safety net"
>>>           }
>>> -    }
>>> -    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>>> -        if { $have_longjmp_probe } {
>>> -        fail $gdb_test_name
>>> -        } else {
>>> -        kfail $gdb_test_name "gdb/26967"
>>> +        -re "miss_step_2.*$::gdb_prompt $" {
>>> +        if { $have_longjmp_probe } {
>>> +            fail $gdb_test_name
>>> +        } else {
>>> +            kfail $gdb_test_name "gdb/26967"
>>> +        }
>>> +        }
>>> +        -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>>> +        if { $have_longjmp_probe } {
>>> +            fail $gdb_test_name
>>> +        } else {
>>> +            kfail $gdb_test_name "gdb/26967"
>>> +        }
>>>           }
>>>       }
>>>       }
>>> -}
>>> -#
>>> -# Pattern 3 - setjmp/longjmp inside stepped-over function.
>>> -#
>>> +    #
>>> +    # Pattern 3 - setjmp/longjmp inside stepped-over function.
>>> +    #
>>> -with_test_prefix "pattern 3" {
>>> +    with_test_prefix "pattern 3" {
>>> -    with_test_prefix setup {
>>> -    delete_breakpoints
>>> +    with_test_prefix setup {
>>> +        delete_breakpoints
>>> -    gdb_test "break $bp_start_test_3" \
>>> -        "Breakpoint.*at.* file .*$srcfile, line.*$bp_start_test_3.*" \
>>> -        "breakpoint at pattern start"
>>> -    gdb_test "continue" "patt3.*" "continue to breakpoint at pattern start"
>>> -    }
>>> -
>>> -    gdb_test_multiple "next" "next over pattern" {
>>> -    -re -wrap "longjmp caught.*" {
>>> -        pass $gdb_test_name
>>> +        gdb_test "break $bp_start_test_3" \
>>> +        "Breakpoint.*at.* file .*$::srcfile, line.*$bp_start_test_3.*" \
>>> +        "breakpoint at pattern start"
>>> +        gdb_test "continue" "patt3.*" "continue to breakpoint at pattern start"
>>>       }
>>> -    -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>>> -        if { $have_longjmp_probe } {
>>> -        fail $gdb_test_name
>>> -        } else {
>>> -        kfail $gdb_test_name "gdb/26967"
>>> +
>>> +    gdb_test_multiple "next" "next over pattern" {
>>> +        -re -wrap "longjmp caught.*" {
>>> +        pass $gdb_test_name
>>> +        }
>>> +        -re -wrap "\r\n$re_cannot_insert_bp\r\n.*" {
>>> +        if { $have_longjmp_probe } {
>>> +            fail $gdb_test_name
>>> +        } else {
>>> +            kfail $gdb_test_name "gdb/26967"
>>> +        }
>>>           }
>>>       }
>>>       }
>>>   }
>>> +
>>> +foreach_with_prefix with_probes { 0 1 } {
>>> +    do_test $with_probes
>>> +}
>>>
>>> base-commit: 0ab9328277ce12014ce05ff139eba7a6230516fd
>>
>
  

On 2/8/23 15:51, Luis Machado wrote:
> On 2/8/23 14:48, Tom de Vries wrote:
>> On 2/8/23 14:27, Luis Machado wrote:
>>> Hi Tom,
>>>
>>> Is the entire test supposed to PASS? I'm seeing the following on my 
>>> aarch64/Ubuntu 22.04 setup:
>>>
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
>>> call_longjmp (the program is no longer running)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
>>> setjmp (the program is no longer running)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>> breakpoint at pattern start (got interactive prompt)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>> breakpoint at safety net (got interactive prompt)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue 
>>> to breakpoint at pattern start (the program exited)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over 
>>> pattern (the program is no longer running)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>> breakpoint at pattern start (got interactive prompt)
>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue 
>>> to breakpoint at pattern start (the program is no longer running)
>>>
>>> Maybe something is genuinely broken for aarch64 though, or I'm 
>>> missing some packages/debuginfo.
>>
>> Hi,
>>
>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems 
>> found.
>>
> 
> Alright. That's good to know.

FWIW, I've tried this test-case also on various x86_64 distros other 
than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse 
tumbleweed, again no problems found.

Thanks,
- Tom
  

On 2/8/23 15:38, Tom de Vries wrote:
> On 2/8/23 15:51, Luis Machado wrote:
>> On 2/8/23 14:48, Tom de Vries wrote:
>>> On 2/8/23 14:27, Luis Machado wrote:
>>>> Hi Tom,
>>>>
>>>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>>>
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>>>
>>>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
>>>
>>> Hi,
>>>
>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
>>>
>>
>> Alright. That's good to know.
> 
> FWIW, I've tried this test-case also on various x86_64 distros other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse tumbleweed, again no problems found.

I did a brief investigation on this one, and gdb seems to be doing something strange.

For Ubuntu 20.04 we have the following, just after deleting the breakpoints leading into the pattern 2 check:


(gdb) info source
Current source file is longjmp.c
Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
Contains 82 lines.
Source language is c.
Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
  -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
tection.
Compiled with DWARF 4 debugging format.
Does not include preprocessor macro info.
(gdb) b 69
Breakpoint 4 at 0xaaaaaaaa08ec: file /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
tsuite/gdb.base/longjmp.c, line 69.
(gdb)

And for Ubuntu 22.04:

(gdb) info source
Current source file is ./setjmp/longjmp.c
Compilation directory is ./setjmp
Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
Contains 82 lines.
Source language is c.
Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protecti
on.
Compiled with DWARF 5 debugging format.
Does not include preprocessor macro info.
(gdb) b 69
No line 69 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb)

There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 for 22.04), source file name and compilation directory.

What is strange is that gdb's 'info source' output seems to refer to the glibc longjmp source file as the current one. And the compilation directory
is also glibc's. The "Located in" field is from the testcase source, also named longjmp.c. The "Contains" line is also based on the testcase source file.

Investigating further, if you "list", it will output the sources from the testcase file as well.

Finally, for 20.04, the "break" command will use the testcase source file, but in 22.04 it will use the glibc source file. I'm guessing the fact that glibc's
source file in 20.04 is also called longjmp.c makes it work somehow. But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess gdb now
attempts to insert a breakpoint in the glibc source file, which doesn't have line 63. So it all goes downhill from there.

I'm not sure if this is a long-standing bug or if it is a somewhat recent regression. But gdb seems to be genuinely confused about which source file is the current one
and which one to use for various commands.

I'd expect gdb to pick one and stick with it, but it doesn't seem to be the case.

Maybe we just uncovered a new bug with source handling.
  

On 2/8/23 19:06, Luis Machado wrote:
> On 2/8/23 15:38, Tom de Vries wrote:
>> On 2/8/23 15:51, Luis Machado wrote:
>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>> Hi Tom,
>>>>>
>>>>> Is the entire test supposed to PASS? I'm seeing the following on my 
>>>>> aarch64/Ubuntu 22.04 setup:
>>>>>
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
>>>>> call_longjmp (the program is no longer running)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
>>>>> setjmp (the program is no longer running)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>> breakpoint at pattern start (got interactive prompt)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>> breakpoint at safety net (got interactive prompt)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>> continue to breakpoint at pattern start (the program exited)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over 
>>>>> pattern (the program is no longer running)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>>>> breakpoint at pattern start (got interactive prompt)
>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>>>> continue to breakpoint at pattern start (the program is no longer 
>>>>> running)
>>>>>
>>>>> Maybe something is genuinely broken for aarch64 though, or I'm 
>>>>> missing some packages/debuginfo.
>>>>
>>>> Hi,
>>>>
>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems 
>>>> found.
>>>>
>>>
>>> Alright. That's good to know.
>>
>> FWIW, I've tried this test-case also on various x86_64 distros other 
>> than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and 
>> opensuse tumbleweed, again no problems found.
> 
> I did a brief investigation on this one, and gdb seems to be doing 
> something strange.
> 
> For Ubuntu 20.04 we have the following, just after deleting the 
> breakpoints leading into the pattern 2 check:
> 
> 
> (gdb) info source
> Current source file is longjmp.c
> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
> Contains 82 lines.
> Source language is c.
> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 
> -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
>   -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec 
> -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
> tection.
> Compiled with DWARF 4 debugging format.
> Does not include preprocessor macro info.
> (gdb) b 69
> Breakpoint 4 at 0xaaaaaaaa08ec: file 
> /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
> tsuite/gdb.base/longjmp.c, line 69.
> (gdb)
> 
> And for Ubuntu 22.04:
> 
> (gdb) info source
> Current source file is ./setjmp/longjmp.c
> Compilation directory is ./setjmp
> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
> Contains 82 lines.
> Source language is c.
> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 
> -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec 
> -fasynchronous-unwind-tables -fstack-protector-strong 
> -fstack-clash-protecti
> on.
> Compiled with DWARF 5 debugging format.
> Does not include preprocessor macro info.
> (gdb) b 69
> No line 69 in the current file.
> Make breakpoint pending on future shared library load? (y or [n]) n
> (gdb)
> 
> There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 
> for 22.04), source file name and compilation directory.
> 
> What is strange is that gdb's 'info source' output seems to refer to the 
> glibc longjmp source file as the current one. And the compilation directory
> is also glibc's. The "Located in" field is from the testcase source, 
> also named longjmp.c. The "Contains" line is also based on the testcase 
> source file.
> 
> Investigating further, if you "list", it will output the sources from 
> the testcase file as well.
> 
> Finally, for 20.04, the "break" command will use the testcase source 
> file, but in 22.04 it will use the glibc source file. I'm guessing the 
> fact that glibc's
> source file in 20.04 is also called longjmp.c makes it work somehow. But 
> in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess 
> gdb now
> attempts to insert a breakpoint in the glibc source file, which doesn't 
> have line 63. So it all goes downhill from there.
> 
> I'm not sure if this is a long-standing bug or if it is a somewhat 
> recent regression. But gdb seems to be genuinely confused about which 
> source file is the current one
> and which one to use for various commands.
> 
> I'd expect gdb to pick one and stick with it, but it doesn't seem to be 
> the case.
> 
> Maybe we just uncovered a new bug with source handling.

I suspect the FAILs will disappear if we replace "break <n>" with "break 
$srcfile:<n>".  I'm not sure yet whether this is a fix or a workaround.

Please file a PR and attach the entire gdb.log, I want to take a look at it.

Thanks,
- Tom
  

On 2/8/23 20:36, Tom de Vries wrote:
> On 2/8/23 19:06, Luis Machado wrote:
>> On 2/8/23 15:38, Tom de Vries wrote:
>>> On 2/8/23 15:51, Luis Machado wrote:
>>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>>> Hi Tom,
>>>>>>
>>>>>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>>>>>
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>>>>>
>>>>>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
>>>>>
>>>>> Hi,
>>>>>
>>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
>>>>>
>>>>
>>>> Alright. That's good to know.
>>>
>>> FWIW, I've tried this test-case also on various x86_64 distros other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse tumbleweed, again no problems found.
>>
>> I did a brief investigation on this one, and gdb seems to be doing something strange.
>>
>> For Ubuntu 20.04 we have the following, just after deleting the breakpoints leading into the pattern 2 check:
>>
>>
>> (gdb) info source
>> Current source file is longjmp.c
>> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>> Contains 82 lines.
>> Source language is c.
>> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
>>   -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
>> tection.
>> Compiled with DWARF 4 debugging format.
>> Does not include preprocessor macro info.
>> (gdb) b 69
>> Breakpoint 4 at 0xaaaaaaaa08ec: file /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
>> tsuite/gdb.base/longjmp.c, line 69.
>> (gdb)
>>
>> And for Ubuntu 22.04:
>>
>> (gdb) info source
>> Current source file is ./setjmp/longjmp.c
>> Compilation directory is ./setjmp
>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>> Contains 82 lines.
>> Source language is c.
>> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
>> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protecti
>> on.
>> Compiled with DWARF 5 debugging format.
>> Does not include preprocessor macro info.
>> (gdb) b 69
>> No line 69 in the current file.
>> Make breakpoint pending on future shared library load? (y or [n]) n
>> (gdb)
>>
>> There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 for 22.04), source file name and compilation directory.
>>
>> What is strange is that gdb's 'info source' output seems to refer to the glibc longjmp source file as the current one. And the compilation directory
>> is also glibc's. The "Located in" field is from the testcase source, also named longjmp.c. The "Contains" line is also based on the testcase source file.
>>
>> Investigating further, if you "list", it will output the sources from the testcase file as well.
>>
>> Finally, for 20.04, the "break" command will use the testcase source file, but in 22.04 it will use the glibc source file. I'm guessing the fact that glibc's
>> source file in 20.04 is also called longjmp.c makes it work somehow. But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess gdb now
>> attempts to insert a breakpoint in the glibc source file, which doesn't have line 63. So it all goes downhill from there.
>>
>> I'm not sure if this is a long-standing bug or if it is a somewhat recent regression. But gdb seems to be genuinely confused about which source file is the current one
>> and which one to use for various commands.
>>
>> I'd expect gdb to pick one and stick with it, but it doesn't seem to be the case.
>>
>> Maybe we just uncovered a new bug with source handling.
> 
> I suspect the FAILs will disappear if we replace "break <n>" with "break $srcfile:<n>".  I'm not sure yet whether this is a fix or a workaround.

I suppose. But it seems there is a different underlying issue of gdb getting confused about what is the current source file.

> 
> Please file a PR and attach the entire gdb.log, I want to take a look at it.

Will do.

> 
> Thanks,
> - Tom
  

On 2/9/23 10:37, Luis Machado via Gdb-patches wrote:
> On 2/8/23 20:36, Tom de Vries wrote:
>> On 2/8/23 19:06, Luis Machado wrote:
>>> On 2/8/23 15:38, Tom de Vries wrote:
>>>> On 2/8/23 15:51, Luis Machado wrote:
>>>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>>>> Hi Tom,
>>>>>>>
>>>>>>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>>>>>>
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>>>>>>
>>>>>>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
>>>>>>
>>>>>
>>>>> Alright. That's good to know.
>>>>
>>>> FWIW, I've tried this test-case also on various x86_64 distros other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse tumbleweed, again no problems found.
>>>
>>> I did a brief investigation on this one, and gdb seems to be doing something strange.
>>>
>>> For Ubuntu 20.04 we have the following, just after deleting the breakpoints leading into the pattern 2 check:
>>>
>>>
>>> (gdb) info source
>>> Current source file is longjmp.c
>>> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>> Contains 82 lines.
>>> Source language is c.
>>> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
>>>   -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
>>> tection.
>>> Compiled with DWARF 4 debugging format.
>>> Does not include preprocessor macro info.
>>> (gdb) b 69
>>> Breakpoint 4 at 0xaaaaaaaa08ec: file /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
>>> tsuite/gdb.base/longjmp.c, line 69.
>>> (gdb)
>>>
>>> And for Ubuntu 22.04:
>>>
>>> (gdb) info source
>>> Current source file is ./setjmp/longjmp.c
>>> Compilation directory is ./setjmp
>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>> Contains 82 lines.
>>> Source language is c.
>>> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
>>> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protecti
>>> on.
>>> Compiled with DWARF 5 debugging format.
>>> Does not include preprocessor macro info.
>>> (gdb) b 69
>>> No line 69 in the current file.
>>> Make breakpoint pending on future shared library load? (y or [n]) n
>>> (gdb)
>>>
>>> There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 for 22.04), source file name and compilation directory.
>>>
>>> What is strange is that gdb's 'info source' output seems to refer to the glibc longjmp source file as the current one. And the compilation directory
>>> is also glibc's. The "Located in" field is from the testcase source, also named longjmp.c. The "Contains" line is also based on the testcase source file.
>>>
>>> Investigating further, if you "list", it will output the sources from the testcase file as well.
>>>
>>> Finally, for 20.04, the "break" command will use the testcase source file, but in 22.04 it will use the glibc source file. I'm guessing the fact that glibc's
>>> source file in 20.04 is also called longjmp.c makes it work somehow. But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess gdb now
>>> attempts to insert a breakpoint in the glibc source file, which doesn't have line 63. So it all goes downhill from there.
>>>
>>> I'm not sure if this is a long-standing bug or if it is a somewhat recent regression. But gdb seems to be genuinely confused about which source file is the current one
>>> and which one to use for various commands.
>>>
>>> I'd expect gdb to pick one and stick with it, but it doesn't seem to be the case.
>>>
>>> Maybe we just uncovered a new bug with source handling.
>>
>> I suspect the FAILs will disappear if we replace "break <n>" with "break $srcfile:<n>".  I'm not sure yet whether this is a fix or a workaround.
> 
> I suppose. But it seems there is a different underlying issue of gdb getting confused about what is the current source file.
> 
>>
>> Please file a PR and attach the entire gdb.log, I want to take a look at it.
> 
> Will do.

Looking around I found https://sourceware.org/bugzilla/show_bug.cgi?id=19474, which seems to indicate some confusing cases aren't really a bug.

> 
>>
>> Thanks,
>> - Tom
>
  

On 2/9/23 12:58, Luis Machado wrote:
> On 2/9/23 10:37, Luis Machado via Gdb-patches wrote:
>> On 2/8/23 20:36, Tom de Vries wrote:
>>> On 2/8/23 19:06, Luis Machado wrote:
>>>> On 2/8/23 15:38, Tom de Vries wrote:
>>>>> On 2/8/23 15:51, Luis Machado wrote:
>>>>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>>>>> Hi Tom,
>>>>>>>>
>>>>>>>> Is the entire test supposed to PASS? I'm seeing the following on 
>>>>>>>> my aarch64/Ubuntu 22.04 setup:
>>>>>>>>
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
>>>>>>>> call_longjmp (the program is no longer running)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over 
>>>>>>>> setjmp (the program is no longer running)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>>>>> breakpoint at pattern start (got interactive prompt)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>>>>> breakpoint at safety net (got interactive prompt)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>>>>> continue to breakpoint at pattern start (the program exited)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over 
>>>>>>>> pattern (the program is no longer running)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>>>>>>> breakpoint at pattern start (got interactive prompt)
>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>>>>>>> continue to breakpoint at pattern start (the program is no 
>>>>>>>> longer running)
>>>>>>>>
>>>>>>>> Maybe something is genuinely broken for aarch64 though, or I'm 
>>>>>>>> missing some packages/debuginfo.
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no 
>>>>>>> problems found.
>>>>>>>
>>>>>>
>>>>>> Alright. That's good to know.
>>>>>
>>>>> FWIW, I've tried this test-case also on various x86_64 distros 
>>>>> other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 
>>>>> and opensuse tumbleweed, again no problems found.
>>>>
>>>> I did a brief investigation on this one, and gdb seems to be doing 
>>>> something strange.
>>>>
>>>> For Ubuntu 20.04 we have the following, just after deleting the 
>>>> breakpoints leading into the pattern 2 check:
>>>>
>>>>
>>>> (gdb) info source
>>>> Current source file is longjmp.c
>>>> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>> Contains 82 lines.
>>>> Source language is c.
>>>> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian 
>>>> -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants 
>>>> -frounding-math
>>>>   -fstack-protector-strong -fmath-errno -fPIC 
>>>> -ftls-model=initial-exec -fasynchronous-unwind-tables 
>>>> -fstack-protector-strong -fstack-clash-pro
>>>> tection.
>>>> Compiled with DWARF 4 debugging format.
>>>> Does not include preprocessor macro info.
>>>> (gdb) b 69
>>>> Breakpoint 4 at 0xaaaaaaaa08ec: file 
>>>> /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
>>>> tsuite/gdb.base/longjmp.c, line 69.
>>>> (gdb)
>>>>
>>>> And for Ubuntu 22.04:
>>>>
>>>> (gdb) info source
>>>> Current source file is ./setjmp/longjmp.c
>>>> Compilation directory is ./setjmp
>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>> Contains 82 lines.
>>>> Source language is c.
>>>> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 
>>>> -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math 
>>>> -fstack-protecto
>>>> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec 
>>>> -fasynchronous-unwind-tables -fstack-protector-strong 
>>>> -fstack-clash-protecti
>>>> on.
>>>> Compiled with DWARF 5 debugging format.
>>>> Does not include preprocessor macro info.
>>>> (gdb) b 69
>>>> No line 69 in the current file.
>>>> Make breakpoint pending on future shared library load? (y or [n]) n
>>>> (gdb)
>>>>
>>>> There is a small difference in debug info (dwarf 4 for 20.04 and 
>>>> dwarf 5 for 22.04), source file name and compilation directory.
>>>>
>>>> What is strange is that gdb's 'info source' output seems to refer to 
>>>> the glibc longjmp source file as the current one. And the 
>>>> compilation directory
>>>> is also glibc's. The "Located in" field is from the testcase source, 
>>>> also named longjmp.c. The "Contains" line is also based on the 
>>>> testcase source file.
>>>>
>>>> Investigating further, if you "list", it will output the sources 
>>>> from the testcase file as well.
>>>>
>>>> Finally, for 20.04, the "break" command will use the testcase source 
>>>> file, but in 22.04 it will use the glibc source file. I'm guessing 
>>>> the fact that glibc's
>>>> source file in 20.04 is also called longjmp.c makes it work somehow. 
>>>> But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I 
>>>> guess gdb now
>>>> attempts to insert a breakpoint in the glibc source file, which 
>>>> doesn't have line 63. So it all goes downhill from there.
>>>>
>>>> I'm not sure if this is a long-standing bug or if it is a somewhat 
>>>> recent regression. But gdb seems to be genuinely confused about 
>>>> which source file is the current one
>>>> and which one to use for various commands.
>>>>
>>>> I'd expect gdb to pick one and stick with it, but it doesn't seem to 
>>>> be the case.
>>>>
>>>> Maybe we just uncovered a new bug with source handling.
>>>
>>> I suspect the FAILs will disappear if we replace "break <n>" with 
>>> "break $srcfile:<n>".  I'm not sure yet whether this is a fix or a 
>>> workaround.
>>
>> I suppose. But it seems there is a different underlying issue of gdb 
>> getting confused about what is the current source file.
>>
>>>
>>> Please file a PR and attach the entire gdb.log, I want to take a look 
>>> at it.
>>
>> Will do.
> 
> Looking around I found 
> https://sourceware.org/bugzilla/show_bug.cgi?id=19474, which seems to 
> indicate some confusing cases aren't really a bug.

Does that mean you're not planning to post the gdb.log?

Thanks,
- Tom
  

On 2/9/23 12:19, Tom de Vries wrote:
> On 2/9/23 12:58, Luis Machado wrote:
>> On 2/9/23 10:37, Luis Machado via Gdb-patches wrote:
>>> On 2/8/23 20:36, Tom de Vries wrote:
>>>> On 2/8/23 19:06, Luis Machado wrote:
>>>>> On 2/8/23 15:38, Tom de Vries wrote:
>>>>>> On 2/8/23 15:51, Luis Machado wrote:
>>>>>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>>>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>>>>>> Hi Tom,
>>>>>>>>>
>>>>>>>>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>>>>>>>>
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>>>>>>>>
>>>>>>>>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
>>>>>>>>
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
>>>>>>>>
>>>>>>>
>>>>>>> Alright. That's good to know.
>>>>>>
>>>>>> FWIW, I've tried this test-case also on various x86_64 distros other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse tumbleweed, again no problems found.
>>>>>
>>>>> I did a brief investigation on this one, and gdb seems to be doing something strange.
>>>>>
>>>>> For Ubuntu 20.04 we have the following, just after deleting the breakpoints leading into the pattern 2 check:
>>>>>
>>>>>
>>>>> (gdb) info source
>>>>> Current source file is longjmp.c
>>>>> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
>>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>>> Contains 82 lines.
>>>>> Source language is c.
>>>>> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
>>>>>   -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
>>>>> tection.
>>>>> Compiled with DWARF 4 debugging format.
>>>>> Does not include preprocessor macro info.
>>>>> (gdb) b 69
>>>>> Breakpoint 4 at 0xaaaaaaaa08ec: file /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
>>>>> tsuite/gdb.base/longjmp.c, line 69.
>>>>> (gdb)
>>>>>
>>>>> And for Ubuntu 22.04:
>>>>>
>>>>> (gdb) info source
>>>>> Current source file is ./setjmp/longjmp.c
>>>>> Compilation directory is ./setjmp
>>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>>> Contains 82 lines.
>>>>> Source language is c.
>>>>> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
>>>>> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protecti
>>>>> on.
>>>>> Compiled with DWARF 5 debugging format.
>>>>> Does not include preprocessor macro info.
>>>>> (gdb) b 69
>>>>> No line 69 in the current file.
>>>>> Make breakpoint pending on future shared library load? (y or [n]) n
>>>>> (gdb)
>>>>>
>>>>> There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 for 22.04), source file name and compilation directory.
>>>>>
>>>>> What is strange is that gdb's 'info source' output seems to refer to the glibc longjmp source file as the current one. And the compilation directory
>>>>> is also glibc's. The "Located in" field is from the testcase source, also named longjmp.c. The "Contains" line is also based on the testcase source file.
>>>>>
>>>>> Investigating further, if you "list", it will output the sources from the testcase file as well.
>>>>>
>>>>> Finally, for 20.04, the "break" command will use the testcase source file, but in 22.04 it will use the glibc source file. I'm guessing the fact that glibc's
>>>>> source file in 20.04 is also called longjmp.c makes it work somehow. But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess gdb now
>>>>> attempts to insert a breakpoint in the glibc source file, which doesn't have line 63. So it all goes downhill from there.
>>>>>
>>>>> I'm not sure if this is a long-standing bug or if it is a somewhat recent regression. But gdb seems to be genuinely confused about which source file is the current one
>>>>> and which one to use for various commands.
>>>>>
>>>>> I'd expect gdb to pick one and stick with it, but it doesn't seem to be the case.
>>>>>
>>>>> Maybe we just uncovered a new bug with source handling.
>>>>
>>>> I suspect the FAILs will disappear if we replace "break <n>" with "break $srcfile:<n>".  I'm not sure yet whether this is a fix or a workaround.
>>>
>>> I suppose. But it seems there is a different underlying issue of gdb getting confused about what is the current source file.
>>>
>>>>
>>>> Please file a PR and attach the entire gdb.log, I want to take a look at it.
>>>
>>> Will do.
>>
>> Looking around I found https://sourceware.org/bugzilla/show_bug.cgi?id=19474, which seems to indicate some confusing cases aren't really a bug.
> 
> Does that mean you're not planning to post the gdb.log?
> 

No. I was creating a new bug when I stopped to read the above one.

I currently have a different set of tests on the logs. I'll reproduce the gdb.base/longjmp.exp FAIL's again and will attach to a new bug. Then we can
decide it is a duplicate or not.

> Thanks,
> - Tom
> 
>
  

On 2/9/23 14:34, Luis Machado via Gdb-patches wrote:
> On 2/9/23 12:19, Tom de Vries wrote:
>> On 2/9/23 12:58, Luis Machado wrote:
>>> On 2/9/23 10:37, Luis Machado via Gdb-patches wrote:
>>>> On 2/8/23 20:36, Tom de Vries wrote:
>>>>> On 2/8/23 19:06, Luis Machado wrote:
>>>>>> On 2/8/23 15:38, Tom de Vries wrote:
>>>>>>> On 2/8/23 15:51, Luis Machado wrote:
>>>>>>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>>>>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>>>>>>> Hi Tom,
>>>>>>>>>>
>>>>>>>>>> Is the entire test supposed to PASS? I'm seeing the following on my aarch64/Ubuntu 22.04 setup:
>>>>>>>>>>
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over call_longjmp (the program is no longer running)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next over setjmp (the program is no longer running)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at pattern start (got interactive prompt)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: breakpoint at safety net (got interactive prompt)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: continue to breakpoint at pattern start (the program exited)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next over pattern (the program is no longer running)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: breakpoint at pattern start (got interactive prompt)
>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: continue to breakpoint at pattern start (the program is no longer running)
>>>>>>>>>>
>>>>>>>>>> Maybe something is genuinely broken for aarch64 though, or I'm missing some packages/debuginfo.
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no problems found.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Alright. That's good to know.
>>>>>>>
>>>>>>> FWIW, I've tried this test-case also on various x86_64 distros other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 and opensuse tumbleweed, again no problems found.
>>>>>>
>>>>>> I did a brief investigation on this one, and gdb seems to be doing something strange.
>>>>>>
>>>>>> For Ubuntu 20.04 we have the following, just after deleting the breakpoints leading into the pattern 2 check:
>>>>>>
>>>>>>
>>>>>> (gdb) info source
>>>>>> Current source file is longjmp.c
>>>>>> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
>>>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>>>> Contains 82 lines.
>>>>>> Source language is c.
>>>>>> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math
>>>>>>   -fstack-protector-strong -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-pro
>>>>>> tection.
>>>>>> Compiled with DWARF 4 debugging format.
>>>>>> Does not include preprocessor macro info.
>>>>>> (gdb) b 69
>>>>>> Breakpoint 4 at 0xaaaaaaaa08ec: file /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
>>>>>> tsuite/gdb.base/longjmp.c, line 69.
>>>>>> (gdb)
>>>>>>
>>>>>> And for Ubuntu 22.04:
>>>>>>
>>>>>> (gdb) info source
>>>>>> Current source file is ./setjmp/longjmp.c
>>>>>> Compilation directory is ./setjmp
>>>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>>>> Contains 82 lines.
>>>>>> Source language is c.
>>>>>> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math -fstack-protecto
>>>>>> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec -fasynchronous-unwind-tables -fstack-protector-strong -fstack-clash-protecti
>>>>>> on.
>>>>>> Compiled with DWARF 5 debugging format.
>>>>>> Does not include preprocessor macro info.
>>>>>> (gdb) b 69
>>>>>> No line 69 in the current file.
>>>>>> Make breakpoint pending on future shared library load? (y or [n]) n
>>>>>> (gdb)
>>>>>>
>>>>>> There is a small difference in debug info (dwarf 4 for 20.04 and dwarf 5 for 22.04), source file name and compilation directory.
>>>>>>
>>>>>> What is strange is that gdb's 'info source' output seems to refer to the glibc longjmp source file as the current one. And the compilation directory
>>>>>> is also glibc's. The "Located in" field is from the testcase source, also named longjmp.c. The "Contains" line is also based on the testcase source file.
>>>>>>
>>>>>> Investigating further, if you "list", it will output the sources from the testcase file as well.
>>>>>>
>>>>>> Finally, for 20.04, the "break" command will use the testcase source file, but in 22.04 it will use the glibc source file. I'm guessing the fact that glibc's
>>>>>> source file in 20.04 is also called longjmp.c makes it work somehow. But in 22.04 the glibc source file is now ./setjmp/longjmp.c, and I guess gdb now
>>>>>> attempts to insert a breakpoint in the glibc source file, which doesn't have line 63. So it all goes downhill from there.
>>>>>>
>>>>>> I'm not sure if this is a long-standing bug or if it is a somewhat recent regression. But gdb seems to be genuinely confused about which source file is the current one
>>>>>> and which one to use for various commands.
>>>>>>
>>>>>> I'd expect gdb to pick one and stick with it, but it doesn't seem to be the case.
>>>>>>
>>>>>> Maybe we just uncovered a new bug with source handling.
>>>>>
>>>>> I suspect the FAILs will disappear if we replace "break <n>" with "break $srcfile:<n>".  I'm not sure yet whether this is a fix or a workaround.
>>>>
>>>> I suppose. But it seems there is a different underlying issue of gdb getting confused about what is the current source file.
>>>>
>>>>>
>>>>> Please file a PR and attach the entire gdb.log, I want to take a look at it.
>>>>
>>>> Will do.
>>>
>>> Looking around I found https://sourceware.org/bugzilla/show_bug.cgi?id=19474, which seems to indicate some confusing cases aren't really a bug.
>>
>> Does that mean you're not planning to post the gdb.log?
>>
> 
> No. I was creating a new bug when I stopped to read the above one.
> 
> I currently have a different set of tests on the logs. I'll reproduce the gdb.base/longjmp.exp FAIL's again and will attach to a new bug. Then we can
> decide it is a duplicate or not.

Done now: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
  

On 2/9/23 17:44, Luis Machado wrote:
> On 2/9/23 14:34, Luis Machado via Gdb-patches wrote:
>> On 2/9/23 12:19, Tom de Vries wrote:
>>> On 2/9/23 12:58, Luis Machado wrote:
>>>> On 2/9/23 10:37, Luis Machado via Gdb-patches wrote:
>>>>> On 2/8/23 20:36, Tom de Vries wrote:
>>>>>> On 2/8/23 19:06, Luis Machado wrote:
>>>>>>> On 2/8/23 15:38, Tom de Vries wrote:
>>>>>>>> On 2/8/23 15:51, Luis Machado wrote:
>>>>>>>>> On 2/8/23 14:48, Tom de Vries wrote:
>>>>>>>>>> On 2/8/23 14:27, Luis Machado wrote:
>>>>>>>>>>> Hi Tom,
>>>>>>>>>>>
>>>>>>>>>>> Is the entire test supposed to PASS? I'm seeing the following 
>>>>>>>>>>> on my aarch64/Ubuntu 22.04 setup:
>>>>>>>>>>>
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next 
>>>>>>>>>>> over call_longjmp (the program is no longer running)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: next 
>>>>>>>>>>> over setjmp (the program is no longer running)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>>>>>>>> breakpoint at pattern start (got interactive prompt)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>>>>>>>> breakpoint at safety net (got interactive prompt)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 2: setup: 
>>>>>>>>>>> continue to breakpoint at pattern start (the program exited)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: next 
>>>>>>>>>>> over pattern (the program is no longer running)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>>>>>>>>>> breakpoint at pattern start (got interactive prompt)
>>>>>>>>>>> FAIL: gdb.base/longjmp.exp: with_probes=0: pattern 3: setup: 
>>>>>>>>>>> continue to breakpoint at pattern start (the program is no 
>>>>>>>>>>> longer running)
>>>>>>>>>>>
>>>>>>>>>>> Maybe something is genuinely broken for aarch64 though, or 
>>>>>>>>>>> I'm missing some packages/debuginfo.
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I just ran this test-case on openSUSE Leap 15.4 aarch64, no 
>>>>>>>>>> problems found.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Alright. That's good to know.
>>>>>>>>
>>>>>>>> FWIW, I've tried this test-case also on various x86_64 distros 
>>>>>>>> other than the usual openSUSE Leap 15.4: ubuntu 20.04, fedora 37 
>>>>>>>> and opensuse tumbleweed, again no problems found.
>>>>>>>
>>>>>>> I did a brief investigation on this one, and gdb seems to be 
>>>>>>> doing something strange.
>>>>>>>
>>>>>>> For Ubuntu 20.04 we have the following, just after deleting the 
>>>>>>> breakpoints leading into the pattern 2 check:
>>>>>>>
>>>>>>>
>>>>>>> (gdb) info source
>>>>>>> Current source file is longjmp.c
>>>>>>> Compilation directory is /build/glibc-RIFKjK/glibc-2.31/setjmp
>>>>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>>>>> Contains 82 lines.
>>>>>>> Source language is c.
>>>>>>> Producer is GNU C11 9.4.0 -moutline-atomics -mlittle-endian 
>>>>>>> -mabi=lp64 -g -O2 -std=gnu11 -fgnu89-inline -fmerge-all-constants 
>>>>>>> -frounding-math
>>>>>>>   -fstack-protector-strong -fmath-errno -fPIC 
>>>>>>> -ftls-model=initial-exec -fasynchronous-unwind-tables 
>>>>>>> -fstack-protector-strong -fstack-clash-pro
>>>>>>> tection.
>>>>>>> Compiled with DWARF 4 debugging format.
>>>>>>> Does not include preprocessor macro info.
>>>>>>> (gdb) b 69
>>>>>>> Breakpoint 4 at 0xaaaaaaaa08ec: file 
>>>>>>> /builds/binutils-gdb-arm64-focal/gdb/testsuite/../../../../repos/binutils-gdb/gdb/tes
>>>>>>> tsuite/gdb.base/longjmp.c, line 69.
>>>>>>> (gdb)
>>>>>>>
>>>>>>> And for Ubuntu 22.04:
>>>>>>>
>>>>>>> (gdb) info source
>>>>>>> Current source file is ./setjmp/longjmp.c
>>>>>>> Compilation directory is ./setjmp
>>>>>>> Located in /repos/binutils-gdb/gdb/testsuite/gdb.base/longjmp.c
>>>>>>> Contains 82 lines.
>>>>>>> Source language is c.
>>>>>>> Producer is GNU C11 11.2.0 -mlittle-endian -mabi=lp64 -g -O2 
>>>>>>> -std=gnu11 -fgnu89-inline -fmerge-all-constants -frounding-math 
>>>>>>> -fstack-protecto
>>>>>>> r-strong -fno-common -fmath-errno -fPIC -ftls-model=initial-exec 
>>>>>>> -fasynchronous-unwind-tables -fstack-protector-strong 
>>>>>>> -fstack-clash-protecti
>>>>>>> on.
>>>>>>> Compiled with DWARF 5 debugging format.
>>>>>>> Does not include preprocessor macro info.
>>>>>>> (gdb) b 69
>>>>>>> No line 69 in the current file.
>>>>>>> Make breakpoint pending on future shared library load? (y or [n]) n
>>>>>>> (gdb)
>>>>>>>
>>>>>>> There is a small difference in debug info (dwarf 4 for 20.04 and 
>>>>>>> dwarf 5 for 22.04), source file name and compilation directory.
>>>>>>>
>>>>>>> What is strange is that gdb's 'info source' output seems to refer 
>>>>>>> to the glibc longjmp source file as the current one. And the 
>>>>>>> compilation directory
>>>>>>> is also glibc's. The "Located in" field is from the testcase 
>>>>>>> source, also named longjmp.c. The "Contains" line is also based 
>>>>>>> on the testcase source file.
>>>>>>>
>>>>>>> Investigating further, if you "list", it will output the sources 
>>>>>>> from the testcase file as well.
>>>>>>>
>>>>>>> Finally, for 20.04, the "break" command will use the testcase 
>>>>>>> source file, but in 22.04 it will use the glibc source file. I'm 
>>>>>>> guessing the fact that glibc's
>>>>>>> source file in 20.04 is also called longjmp.c makes it work 
>>>>>>> somehow. But in 22.04 the glibc source file is now 
>>>>>>> ./setjmp/longjmp.c, and I guess gdb now
>>>>>>> attempts to insert a breakpoint in the glibc source file, which 
>>>>>>> doesn't have line 63. So it all goes downhill from there.
>>>>>>>
>>>>>>> I'm not sure if this is a long-standing bug or if it is a 
>>>>>>> somewhat recent regression. But gdb seems to be genuinely 
>>>>>>> confused about which source file is the current one
>>>>>>> and which one to use for various commands.
>>>>>>>
>>>>>>> I'd expect gdb to pick one and stick with it, but it doesn't seem 
>>>>>>> to be the case.
>>>>>>>
>>>>>>> Maybe we just uncovered a new bug with source handling.
>>>>>>
>>>>>> I suspect the FAILs will disappear if we replace "break <n>" with 
>>>>>> "break $srcfile:<n>".  I'm not sure yet whether this is a fix or a 
>>>>>> workaround.
>>>>>
>>>>> I suppose. But it seems there is a different underlying issue of 
>>>>> gdb getting confused about what is the current source file.
>>>>>
>>>>>>
>>>>>> Please file a PR and attach the entire gdb.log, I want to take a 
>>>>>> look at it.
>>>>>
>>>>> Will do.
>>>>
>>>> Looking around I found 
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=19474, which seems 
>>>> to indicate some confusing cases aren't really a bug.
>>>
>>> Does that mean you're not planning to post the gdb.log?
>>>
>>
>> No. I was creating a new bug when I stopped to read the above one.
>>
>> I currently have a different set of tests on the logs. I'll reproduce 
>> the gdb.base/longjmp.exp FAIL's again and will attach to a new bug. 
>> Then we can
>> decide it is a duplicate or not.
> 
> Done now: https://sourceware.org/bugzilla/show_bug.cgi?id=30103
> 

Ack, understood, thanks for posting it.

I've submitted a patch here ( 
https://sourceware.org/pipermail/gdb-patches/2023-February/196807.html ).

Thanks,
- Tom