[PATCH][gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp

[PATCH][gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp

[Tom de Vries]

Hi,

When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get:
...
(gdb) up 3^M
79      abort.c: No such file or directory.^M
(gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame
...

The preceding backtrace looks like this:
...
(gdb) bt^M
 #0  0xf7fcf549 in __kernel_vsyscall ()^M
 #1  0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \
     ../sysdeps/unix/sysv/linux/internal-signals.h:104^M
 #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M
 #3  0xf7cd0314 in __GI_abort () at abort.c:79^M
 #4  0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M
 #5  0x08049176 in main () at i386-gnu-cfi.c:27^M
...
with function gate at position #4, while on another system where the test passes,
I see instead:
...
(gdb) PASS: gdb.arch/i386-gnu-cfi.exp: continue to abort()
backtrace^M
(gdb) PASS: gdb.arch/i386-gnu-cfi.exp: backtrace
...
function gate at position #3.

Fix this by capturing the position of function gate in the backtrace, and
using that in the rest of the test instead of hardcoded constant 3.

Tested on x86_64-linux.

Any comments?

Thanks,
- Tom

[gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp

gdb/testsuite/ChangeLog:

2021-01-26  Tom de Vries  <tdevries@suse.de>

	* gdb.arch/i386-gnu-cfi.exp: Capturing the position of function gate
	in the backtrace, and use that in the rest of the test instead of
	hardcoded constant 3.

---
 gdb/testsuite/gdb.arch/i386-gnu-cfi.exp | 22 +++++++++++++++++-----
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
index 4228140fc35..8f6fbb8bf44 100644
--- a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
+++ b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
@@ -60,19 +60,31 @@ gdb_test_multiple {} "continue to abort()" {
 
 # Backtrace would crash before.
 
-gdb_test "bt" \
-         "main \\(\\) at .*${testfile}.c.*" \
-         "backtrace"
+set gate_n ""
+set backtrace_re \
+    [multi_line \
+	 "" \
+	 "#($decimal) *$hex in gate \[^\r\n\]*" \
+	 "#$decimal *$hex in main \\(\\) at .*${testfile}.c.*"]
+gdb_test_multiple "backtrace" "" {
+    -re -wrap $backtrace_re {
+	set gate_n $expect_out(1,string)
+	pass $gdb_test_name
+    }
+}
+if { $gate_n == "" } {
+    return -1
+}
 
 # Check we see the inserted `DW_CFA_GNU_negative_offset_extended' CFI.
 # We see there the original CFI-stored filename `gate.c'.
 
-gdb_test "up 3" \
+gdb_test "up $gate_n" \
          "gate \\(\[^()\]*\\) at .*gate.c.*" \
          "shift up to the modified frame"
 
 gdb_test_multiple "info frame" "existence of the CFI inserted register" {
-    -re "Stack level 3, frame at (0x\[0-9a-f\]+):.*Saved registers:.* ecx at (0x\[0-9a-f\]+),.*" {
+    -re "Stack level $gate_n, frame at (0x\[0-9a-f\]+):.*Saved registers:.* ecx at (0x\[0-9a-f\]+),.*" {
 	pass "existence of the CFI inserted register"
 	if { [string compare $expect_out(1,string) $expect_out(2,string)] } then {
 	    fail "value of the CFI inserted register"

Re: [PATCH][gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp

[Simon Marchi]

On 2021-01-26 1:04 p.m., Tom de Vries wrote:
> Hi,
> 
> When running test-case gdb.arch/i386-gnu-cfi.exp with target board unix/-m32, I get:
> ...
> (gdb) up 3^M
> 79      abort.c: No such file or directory.^M
> (gdb) FAIL: gdb.arch/i386-gnu-cfi.exp: shift up to the modified frame
> ...
> 
> The preceding backtrace looks like this:
> ...
> (gdb) bt^M
>  #0  0xf7fcf549 in __kernel_vsyscall ()^M
>  #1  0xf7ce8896 in __libc_signal_restore_set (set=0xffffc3bc) at \
>      ../sysdeps/unix/sysv/linux/internal-signals.h:104^M
>  #2  __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:47^M
>  #3  0xf7cd0314 in __GI_abort () at abort.c:79^M
>  #4  0x0804919f in gate (gate=0x8049040 <abort@plt>, data=0x0) at gate.c:3^M
>  #5  0x08049176 in main () at i386-gnu-cfi.c:27^M
> ...
> with function gate at position #4, while on another system where the test passes,
> I see instead:
> ...
> (gdb) PASS: gdb.arch/i386-gnu-cfi.exp: continue to abort()
> backtrace^M
> (gdb) PASS: gdb.arch/i386-gnu-cfi.exp: backtrace
> ...
> function gate at position #3.
> 
> Fix this by capturing the position of function gate in the backtrace, and
> using that in the rest of the test instead of hardcoded constant 3.
> 
> Tested on x86_64-linux.
> 
> Any comments?
> 
> Thanks,
> - Tom
> 
> [gdb/testsuite] Fix gdb.arch/i386-gnu-cfi.exp
> 
> gdb/testsuite/ChangeLog:
> 
> 2021-01-26  Tom de Vries  <tdevries@suse.de>
> 
> 	* gdb.arch/i386-gnu-cfi.exp: Capturing the position of function gate
> 	in the backtrace, and use that in the rest of the test instead of
> 	hardcoded constant 3.
> 
> ---
>  gdb/testsuite/gdb.arch/i386-gnu-cfi.exp | 22 +++++++++++++++++-----
>  1 file changed, 17 insertions(+), 5 deletions(-)
> 
> diff --git a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
> index 4228140fc35..8f6fbb8bf44 100644
> --- a/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
> +++ b/gdb/testsuite/gdb.arch/i386-gnu-cfi.exp
> @@ -60,19 +60,31 @@ gdb_test_multiple {} "continue to abort()" {
>  
>  # Backtrace would crash before.
>  
> -gdb_test "bt" \
> -         "main \\(\\) at .*${testfile}.c.*" \
> -         "backtrace"
> +set gate_n ""
> +set backtrace_re \
> +    [multi_line \
> +	 "" \
> +	 "#($decimal) *$hex in gate \[^\r\n\]*" \
> +	 "#$decimal *$hex in main \\(\\) at .*${testfile}.c.*"]
> +gdb_test_multiple "backtrace" "" {
> +    -re -wrap $backtrace_re {
> +	set gate_n $expect_out(1,string)
> +	pass $gdb_test_name
> +    }
> +}

Please add a comment above this describing the intent, finding the frame number
for function "gate". 

> +if { $gate_n == "" } {
> +    return -1
> +}
>  
>  # Check we see the inserted `DW_CFA_GNU_negative_offset_extended' CFI.
>  # We see there the original CFI-stored filename `gate.c'.
>  
> -gdb_test "up 3" \
> +gdb_test "up $gate_n" \
>           "gate \\(\[^()\]*\\) at .*gate.c.*" \
>           "shift up to the modified frame"

Since $gate_n is the frame number, perhaps use the "frame" command instead?

It still works with "up" because frame #0 is initially selected, but using
"frame" would be more robust.

Otherwise, LGTM.

Simon