[PATCH v4 00/15] Clean gdb.base when testing with clang

[PATCH v4 00/15] Clean gdb.base when testing with clang

[Bruno Larsen]

When testing GDB with clang, gdb.base had over 50 more failures than when
testing with gcc.  Examining the failed tests led to a few clang bugs, a
few GDB bugs, and many testsuite assumptions that could be changed.

After this patch series, nothing should be changed for testing with gcc,
and testing with clang should only show non-trivial failures for
maint.exp and macscp.exp, along with the same GCC failures.

Changes in v4:
    * Added new test to step through a function's epoligue
    * renamed gdb_step_until_regexp -> gdb_step_until
    * small style and wording changes in patches 1 and 2
    * Dropped patch 3 - no longer necessary
    * patch 4 was reworked based on Andrew's suggestion
small note, Andrew has OK'd patched 5 and 6 (currently 4 and 5) in v3;

Changes in v3:
    * Fixed some issues that only showed up on CXX_FOR_TARGET=clang
    * rebased on current master

Changes in v2:
    * Introduced gdb_step_until_regexp, based on Pedro's and Andrew's suggestions
    * reworked fixes for: skip.exp, skip-solib.exp and msym-bp-shl.exp
    * Used Pedro's suggestion for call-ar-st
    * reordered patches slightly

Bruno Larsen (15):
  gdb/testsuite: introduce gdb_step_until
  gdb/testsuite: Add a proc to test where compiler links the epilogue
  Change gdb.base/skip-solib.exp deal with lack of epilogue information
  gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
  update gdb.base/info-program.exp to not fail with clang
  fix gdb.base/access-mem-running.exp for clang testing
  Fix gdb.base/call-ar-st to work with Clang
  add xfails to gdb.base/complex-parts.exp when testing with clang
  gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang
  explicitly test for stderr in gdb.base/dprintf.exp
  gdb/testsuite: Update gdb.base/so-impl-ld.exp
  [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang
  gdb/testsuite: fix gdb.base/info-types-c++ with clang
  gdb.base/skip.exp: Use finish to exit functions
  gdb/testsuite: Add test to step through function epilogue

 gdb/testsuite/gdb.base/access-mem-running.c   |   2 +-
 gdb/testsuite/gdb.base/call-ar-st.exp         |  13 ++-
 gdb/testsuite/gdb.base/complex-parts.exp      |   5 +
 gdb/testsuite/gdb.base/dprintf.exp            |  10 ++
 gdb/testsuite/gdb.base/info-program.exp       |   2 +-
 gdb/testsuite/gdb.base/info-types.exp.tcl     | 109 ++++++++++++------
 gdb/testsuite/gdb.base/jit-elf.exp            |   2 +-
 gdb/testsuite/gdb.base/msym-bp-shl.exp        |   8 ++
 gdb/testsuite/gdb.base/nodebug.exp            |  12 +-
 gdb/testsuite/gdb.base/skip-inline.exp        |  23 ++--
 gdb/testsuite/gdb.base/skip-solib-lib.c       |   3 +-
 gdb/testsuite/gdb.base/skip-solib-main.c      |   3 +-
 gdb/testsuite/gdb.base/skip-solib.exp         |  12 +-
 gdb/testsuite/gdb.base/skip.exp               |  32 +++--
 gdb/testsuite/gdb.base/so-impl-ld.exp         |  13 +--
 gdb/testsuite/gdb.base/solib1.c               |   5 +-
 .../gdb.base/step-through-epilogue.c          |  15 +++
 .../gdb.base/step-through-epilogue.exp        |  86 ++++++++++++++
 gdb/testsuite/lib/gdb.exp                     |  62 ++++++++++
 19 files changed, 334 insertions(+), 83 deletions(-)
 create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
 create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp

-- 
2.31.1

[PATCH v4 01/15] gdb/testsuite: introduce gdb_step_until

[Bruno Larsen]

Currently, GDB's testsuite uses a set amount of step commands to exit
functions. This is a problem if a compiler emits different epilogue
information from gcc, or emits no epilogue information at all. It was
most noticeable if Clang was used to test GDB.

To fix this unreliability, this commit introduces a new proc that will
step the inferior until it is stopped at a line that matches the given
regexp, or until it steps too many times - defined as an optional
argument. If the line is found, it shows up as a single PASS in the
test, and if the line is not found, a single FAIL is emitted.

This patch only introduces this proc, but does not add it to any
existing tests, these will be introduced in the following commit.
---
 gdb/testsuite/lib/gdb.exp | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 698dd14504e..aae5cb31255 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -8832,5 +8832,35 @@ gdb_caching_proc arm_cc_for_target {
     return ""
 }
 
+# Step until the pattern REGEXP is found.  Step at most
+# MAX_STEPS times, but stop stepping once REGEXP is found.
+#
+# If REGEXP is found then a single pass is emitted, otherwise, after
+# MAX_STEPS steps, a single fail is emitted.
+#
+# TEST_NAME is the name used in the pass/fail calls.
+
+proc gdb_step_until { regexp {test_name ""} {max_steps 10} } {
+    if { $test_name == "" } {
+	set test_name "stepping until regexp"
+    }
+
+    set count 0
+    gdb_test_multiple "step" "$test_name" {
+	-re "$regexp\r\n$::gdb_prompt $" {
+	    pass $test_name
+	}
+	-re ".*$::gdb_prompt $" {
+	    if {$count < $max_steps} {
+		incr count
+		send_gdb "step\n"
+		exp_continue
+	    } else {
+		fail $test_name
+	    }
+	}
+    }
+}
+
 # Always load compatibility stuff.
 load_lib future.exp
-- 
2.31.1

[PATCH v4 01/15] gdb/testsuite: introduce gdb_step_until_regexp

[Bruno Larsen]

Currently, GDB's testsuite uses a set amount of step commands to exit
functions. This is a problem if a compiler emits different epilogue
information from gcc, or emits no epilogue information at all. It was
most noticeable if Clang was used to test GDB.

To fix this unreliability, this commit introduces a new proc that will
step the inferior until it is stopped at a line that matches the given
regexp, or until it steps too many times - defined as an optional
argument. If the line is found, it shows up as a single PASS in the
test, and if the line is not found, a single FAIL is emitted.

This patch only introduces this proc, but does not add it to any
existing tests, these will be introduced in the following commit.
---
 gdb/testsuite/lib/gdb.exp | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index 698dd14504e..aae5cb31255 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -8832,5 +8832,35 @@ gdb_caching_proc arm_cc_for_target {
     return ""
 }
 
+# Step until the pattern REGEXP is found.  Step at most
+# MAX_STEPS times, but stop stepping once REGEXP is found.
+#
+# If REGEXP is found then a single pass is emitted, otherwise, after
+# MAX_STEPS steps, a single fail is emitted.
+#
+# TEST_NAME is the name used in the pass/fail calls.
+
+proc gdb_step_until { regexp {test_name ""} {max_steps 10} } {
+    if { $test_name == "" } {
+	set test_name "stepping until regexp"
+    }
+
+    set count 0
+    gdb_test_multiple "step" "$test_name" {
+	-re "$regexp\r\n$::gdb_prompt $" {
+	    pass $test_name
+	}
+	-re ".*$::gdb_prompt $" {
+	    if {$count < $max_steps} {
+		incr count
+		send_gdb "step\n"
+		exp_continue
+	    } else {
+		fail $test_name
+	    }
+	}
+    }
+}
+
 # Always load compatibility stuff.
 load_lib future.exp
-- 
2.31.1

[PATCH v4 02/15] gdb/testsuite: Add a proc to test where compiler links the epilogue

[Bruno Larsen]

Different compilers link the epilogue of functions to different lines.
As an example, gcc links it to the closing brace of the function,
whereas clang links it to the last statement of the function.  This
difference is important for the testsuite, since the where GDB will land
after a step can be wildly different.  Where possible, this dependency
should be side-stepped in the testsuite, but it isn't always possible,
so this commit adds a gdb_caching_proc that is able to detect where the
epilogue is linked, so tests can react accordingly.
---
 gdb/testsuite/lib/gdb.exp | 32 ++++++++++++++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index aae5cb31255..6c8eb472041 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -8862,5 +8862,37 @@ proc gdb_step_until { regexp {test_name ""} {max_steps 10} } {
     }
 }
 
+# Check if the compiler emits epilogue information associated
+# with the closing brace or with the last statement line.
+#
+# This proc restarts GDB
+#
+# Returns True if it is associated with the closing brace,
+# False if it is the last statement
+gdb_caching_proc have_epilogue_line_info {
+
+    set main {
+	int
+	main ()
+	{
+	    return 0;
+	}
+    }
+    if {![gdb_simple_compile "simple_program" $main]} {
+	 return False
+    }
+
+    clean_restart $obj
+
+    gdb_test_multiple "info line 6" "epilogue test" {
+	-re -wrap ".*starts at address.*and ends at.*" {
+	    return True
+	}
+	-re -wrap ".*" {
+	    return False
+	}
+    }
+}
+
 # Always load compatibility stuff.
 load_lib future.exp
-- 
2.31.1

Re: [PATCH v4 02/15] gdb/testsuite: Add a proc to test where compiler links the epilogue

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> Different compilers link the epilogue of functions to different lines.
> As an example, gcc links it to the closing brace of the function,
> whereas clang links it to the last statement of the function.  This
> difference is important for the testsuite, since the where GDB will land
> after a step can be wildly different.  Where possible, this dependency
> should be side-stepped in the testsuite, but it isn't always possible,
> so this commit adds a gdb_caching_proc that is able to detect where the
> epilogue is linked, so tests can react accordingly.

This looks fine to me.  You can merge this once you have a patch that
depends on this that is ready to merge.

Thanks,
Andrew

> ---
>  gdb/testsuite/lib/gdb.exp | 32 ++++++++++++++++++++++++++++++++
>  1 file changed, 32 insertions(+)
>
> diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
> index aae5cb31255..6c8eb472041 100644
> --- a/gdb/testsuite/lib/gdb.exp
> +++ b/gdb/testsuite/lib/gdb.exp
> @@ -8862,5 +8862,37 @@ proc gdb_step_until { regexp {test_name ""} {max_steps 10} } {
>      }
>  }
>  
> +# Check if the compiler emits epilogue information associated
> +# with the closing brace or with the last statement line.
> +#
> +# This proc restarts GDB
> +#
> +# Returns True if it is associated with the closing brace,
> +# False if it is the last statement
> +gdb_caching_proc have_epilogue_line_info {
> +
> +    set main {
> +	int
> +	main ()
> +	{
> +	    return 0;
> +	}
> +    }
> +    if {![gdb_simple_compile "simple_program" $main]} {
> +	 return False
> +    }
> +
> +    clean_restart $obj
> +
> +    gdb_test_multiple "info line 6" "epilogue test" {
> +	-re -wrap ".*starts at address.*and ends at.*" {
> +	    return True
> +	}
> +	-re -wrap ".*" {
> +	    return False
> +	}
> +    }
> +}
> +
>  # Always load compatibility stuff.
>  load_lib future.exp
> -- 
> 2.31.1

[PATCH v4 03/15] Change gdb.base/skip-solib.exp deal with lack of epilogue information

[Bruno Larsen]

When running gdb.base/skip-solib.exp, the backtrace tests could fail with
compilers that associated epilogue instructions with the last statement
line of the function, instead of associating it with the closing brace,
despite the feature being fully functional.  As an example, when testing
skipping the function square, the testsuite would show

Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5
5         return square(0);
(gdb) step
0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
(gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step
bt
 #0  0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
 #1  0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6
 #2  0x0000000000401065 in _start ()
(gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt

Which means that the feature is working, the testsuite is just
mis-identifying it.  To avoid this problem, the skipped function calls
have been sent to a line before `return`, so epilogues won't factor in.

This commit has also changed a few hardcoded steps to leave functions to
the newly introduced gdb_step_until to leave those functions.
---
 gdb/testsuite/gdb.base/skip-inline.exp   | 23 ++++++++++++++++-------
 gdb/testsuite/gdb.base/skip-solib-lib.c  |  3 ++-
 gdb/testsuite/gdb.base/skip-solib-main.c |  3 ++-
 gdb/testsuite/gdb.base/skip-solib.exp    | 12 ++++++++++--
 4 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/gdb/testsuite/gdb.base/skip-inline.exp b/gdb/testsuite/gdb.base/skip-inline.exp
index f6e9926b66c..3fbaa5469dd 100644
--- a/gdb/testsuite/gdb.base/skip-inline.exp
+++ b/gdb/testsuite/gdb.base/skip-inline.exp
@@ -15,6 +15,11 @@
 
 standard_testfile
 
+set epilogue 1
+if {![have_epilogue_line_info]} {
+    set epilogue 0
+}
+
 if { [prepare_for_testing "failed to prepare" "skip-inline" \
 			  {skip-inline.c skip1.c } \
 			  {debug nowarnings}] } {
@@ -35,16 +40,20 @@ gdb_test "skip function foo" "Function foo will be skipped when stepping\."
 gdb_test "bt" "\\s*\\#0\\s+main.*" "in the main"
 gdb_test "step" ".*" "step into baz, since foo will be skipped"
 gdb_test "bt" "\\s*\\#0\\s+baz.*" "in the baz, since foo was skipped"
-gdb_test "step" ".*" "step in the baz"
-gdb_test "bt" "\\s*\\#0\\s+baz.*" "still in the baz"
-gdb_test "step" ".*" "step back to main"
+gdb_step_until ".*x = 0; x = baz \\(foo \\(\\)\\).*"
 gdb_test "bt" "\\s*\\#0\\s+main.*" "again in the main"
 gdb_test "step" ".*" "step again into baz, since foo will be skipped"
 gdb_test "bt" "\\s*\\#0\\s+baz.*" "again in the baz"
-gdb_test "step" ".*" "step in the baz, again"
-gdb_test "bt" "\\s*\\#0\\s+baz.*" "still in the baz, again"
-gdb_test "step" ".*" "step back to main, again"
-gdb_test "bt" "\\s*\\#0\\s+main.*" "again back to main"
+gdb_step_until "main \\(\\) at .*" "step back to main, again"
+gdb_test "bt" "\\s*\\#0.*main.*" "again back to main"
+
+# Because clang doesn't add epilogue information, having a set number of
+# steps puts clang more and more out of sync with gcc.  It is unlikely that
+# the effort of keeping both outputs will be useful.
+if {$epilogue == 0} {
+    untested "Multiple steps tests are not supported with this compiler"
+    return
+}
 
 if ![runto_main] {
     return
diff --git a/gdb/testsuite/gdb.base/skip-solib-lib.c b/gdb/testsuite/gdb.base/skip-solib-lib.c
index b2c4d86d703..341f1440a3b 100644
--- a/gdb/testsuite/gdb.base/skip-solib-lib.c
+++ b/gdb/testsuite/gdb.base/skip-solib-lib.c
@@ -7,5 +7,6 @@ int multiply(int a, int b)
 
 int square(int num)
 {
-  return multiply(num, num);
+  int res = multiply(num, num);
+  return res;
 }
diff --git a/gdb/testsuite/gdb.base/skip-solib-main.c b/gdb/testsuite/gdb.base/skip-solib-main.c
index 746bb5f36bb..a3b6d417935 100644
--- a/gdb/testsuite/gdb.base/skip-solib-main.c
+++ b/gdb/testsuite/gdb.base/skip-solib-main.c
@@ -2,5 +2,6 @@ int square(int num);
 
 int main()
 {
-  return square(0);
+  int s = square(0);
+  return s;
 }
diff --git a/gdb/testsuite/gdb.base/skip-solib.exp b/gdb/testsuite/gdb.base/skip-solib.exp
index 0f2ce7e1ad8..8e61725ad1b 100644
--- a/gdb/testsuite/gdb.base/skip-solib.exp
+++ b/gdb/testsuite/gdb.base/skip-solib.exp
@@ -82,7 +82,7 @@ with_test_prefix "ignoring solib file" {
     # We shouldn't step into square(), since we skipped skip-solib-lib.c.
     #
     gdb_test "step" ""
-    gdb_test "bt" "#0\\s+main.*"
+    gdb_test "bt 1" "#0\\s+main.*"
 }
 
 #
@@ -114,5 +114,13 @@ with_test_prefix "ignoring solib function" {
     # the last line of square.
     #
     gdb_test "step" ""
-    gdb_test "bt" "#0\\s+square.*"
+    gdb_test "bt 1" "#0\\s+square.*" "skipped multiply"
+#    gdb_test_multiple "bt 1" "skipped multiply" {
+#	-re "#0\\s+square.*" {
+#	    pass "skipped multiply"
+#	}
+#	-re "#0.*main.*" {
+#	    pass "skipped multiply"
+#	}
+#    }
 }
-- 
2.31.1

Re: [PATCH v4 03/15] Change gdb.base/skip-solib.exp deal with lack of epilogue information

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> When running gdb.base/skip-solib.exp, the backtrace tests could fail with
> compilers that associated epilogue instructions with the last statement
> line of the function, instead of associating it with the closing brace,
> despite the feature being fully functional.  As an example, when testing
> skipping the function square, the testsuite would show
>
> Breakpoint 1, main () at (...)/binutils-gdb/gdb/testsuite/gdb.base/skip-solib-main.c:5
> 5         return square(0);
> (gdb) step
> 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
> (gdb) PASS: gdb.base/skip-solib.exp: ignoring solib file: step
> bt
>  #0  0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6
>  #1  0x00007ffff7cef60c in __libc_start_main_impl () from /lib64/libc.so.6
>  #2  0x0000000000401065 in _start ()
> (gdb) FAIL: gdb.base/skip-solib.exp: ignoring solib file: bt
>
> Which means that the feature is working, the testsuite is just
> mis-identifying it.  To avoid this problem, the skipped function calls
> have been sent to a line before `return`, so epilogues won't factor in.
>
> This commit has also changed a few hardcoded steps to leave functions to
> the newly introduced gdb_step_until to leave those functions.

I think I would like to see the skip-inline.exp change moved into a
separate commit given it's a completely different type of fix.

> ---
>  gdb/testsuite/gdb.base/skip-inline.exp   | 23 ++++++++++++++++-------
>  gdb/testsuite/gdb.base/skip-solib-lib.c  |  3 ++-
>  gdb/testsuite/gdb.base/skip-solib-main.c |  3 ++-
>  gdb/testsuite/gdb.base/skip-solib.exp    | 12 ++++++++++--
>  4 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/skip-inline.exp b/gdb/testsuite/gdb.base/skip-inline.exp
> index f6e9926b66c..3fbaa5469dd 100644
> --- a/gdb/testsuite/gdb.base/skip-inline.exp
> +++ b/gdb/testsuite/gdb.base/skip-inline.exp
> @@ -15,6 +15,11 @@
>  
>  standard_testfile
>  
> +set epilogue 1
> +if {![have_epilogue_line_info]} {
> +    set epilogue 0
> +}

I think 'set epilogue [have_epilogue_line_info]' would be better.

> +
>  if { [prepare_for_testing "failed to prepare" "skip-inline" \
>  			  {skip-inline.c skip1.c } \
>  			  {debug nowarnings}] } {
> @@ -35,16 +40,20 @@ gdb_test "skip function foo" "Function foo will be skipped when stepping\."
>  gdb_test "bt" "\\s*\\#0\\s+main.*" "in the main"
>  gdb_test "step" ".*" "step into baz, since foo will be skipped"
>  gdb_test "bt" "\\s*\\#0\\s+baz.*" "in the baz, since foo was skipped"
> -gdb_test "step" ".*" "step in the baz"
> -gdb_test "bt" "\\s*\\#0\\s+baz.*" "still in the baz"
> -gdb_test "step" ".*" "step back to main"
> +gdb_step_until ".*x = 0; x = baz \\(foo \\(\\)\\).*"
>  gdb_test "bt" "\\s*\\#0\\s+main.*" "again in the main"
>  gdb_test "step" ".*" "step again into baz, since foo will be skipped"
>  gdb_test "bt" "\\s*\\#0\\s+baz.*" "again in the baz"
> -gdb_test "step" ".*" "step in the baz, again"
> -gdb_test "bt" "\\s*\\#0\\s+baz.*" "still in the baz, again"
> -gdb_test "step" ".*" "step back to main, again"
> -gdb_test "bt" "\\s*\\#0\\s+main.*" "again back to main"
> +gdb_step_until "main \\(\\) at .*" "step back to main, again"
> +gdb_test "bt" "\\s*\\#0.*main.*" "again back to main"
> +
> +# Because clang doesn't add epilogue information, having a set number of
> +# steps puts clang more and more out of sync with gcc.  It is unlikely that
> +# the effort of keeping both outputs will be useful.
> +if {$epilogue == 0} {

Just 'if { !$epilogue } {' would be better.

> +    untested "Multiple steps tests are not supported with this compiler"
> +    return
> +}

I notice that there's actually another test at the end of this file that
doesn't rely on multiple steps, which we now end up skipping due to this
early return.

I wonder if this test file would be better structured something like:

  proc_with_prefix single_step { } {
    # The first block of tests that just does 'step'.
  }
  
  proc_with_prefix double_step { } {
    # The second block of tests that do 'step 2'.
  }
  
  proc_with_prefix triple_step { } {
    # The third block of tests that do 'step 3'.
  }
  
  proc_with_prefix skip_current_frame { } {
    # The final bit of test that sets up a skip of foo.
  }
  
  single_step
  if { $epilogue } {
    double_step
    triple_step
  }
  skip_current_frame

>  
>  if ![runto_main] {
>      return
> diff --git a/gdb/testsuite/gdb.base/skip-solib-lib.c b/gdb/testsuite/gdb.base/skip-solib-lib.c
> index b2c4d86d703..341f1440a3b 100644
> --- a/gdb/testsuite/gdb.base/skip-solib-lib.c
> +++ b/gdb/testsuite/gdb.base/skip-solib-lib.c
> @@ -7,5 +7,6 @@ int multiply(int a, int b)
>  
>  int square(int num)
>  {
> -  return multiply(num, num);
> +  int res = multiply(num, num);
> +  return res;
>  }
> diff --git a/gdb/testsuite/gdb.base/skip-solib-main.c b/gdb/testsuite/gdb.base/skip-solib-main.c
> index 746bb5f36bb..a3b6d417935 100644
> --- a/gdb/testsuite/gdb.base/skip-solib-main.c
> +++ b/gdb/testsuite/gdb.base/skip-solib-main.c
> @@ -2,5 +2,6 @@ int square(int num);
>  
>  int main()
>  {
> -  return square(0);
> +  int s = square(0);
> +  return s;
>  }
> diff --git a/gdb/testsuite/gdb.base/skip-solib.exp b/gdb/testsuite/gdb.base/skip-solib.exp
> index 0f2ce7e1ad8..8e61725ad1b 100644
> --- a/gdb/testsuite/gdb.base/skip-solib.exp
> +++ b/gdb/testsuite/gdb.base/skip-solib.exp
> @@ -82,7 +82,7 @@ with_test_prefix "ignoring solib file" {
>      # We shouldn't step into square(), since we skipped skip-solib-lib.c.
>      #
>      gdb_test "step" ""
> -    gdb_test "bt" "#0\\s+main.*"
> +    gdb_test "bt 1" "#0\\s+main.*"
>  }
>  
>  #
> @@ -114,5 +114,13 @@ with_test_prefix "ignoring solib function" {
>      # the last line of square.
>      #
>      gdb_test "step" ""
> -    gdb_test "bt" "#0\\s+square.*"
> +    gdb_test "bt 1" "#0\\s+square.*" "skipped multiply"
> +#    gdb_test_multiple "bt 1" "skipped multiply" {
> +#	-re "#0\\s+square.*" {
> +#	    pass "skipped multiply"
> +#	}
> +#	-re "#0.*main.*" {
> +#	    pass "skipped multiply"
> +#	}
> +#    }

This commented out code should be removed.

In fact, I wonder if any of the changes in skip-solib.exp are actually
needed.  Sure, 'bt 1' is maybe a little more specific than 'bt', but
given the pattern we check for doesn't change, I don't think this change
should make any difference.

If this is just a preference/cleanup then this should probably move into
a sperate patch to avoid any confusion.  Or just drop this part?

Thanks,
Andrew
>  }
> -- 
> 2.31.1

[PATCH v4 04/15] gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang

[Bruno Larsen]

Clang organizes the variables differently to gcc in the original version
of this code, leading to the following differences when testing
p (int*) &dataglobal + 1

gcc:
$16 = (int *) 0x404034 <datalocal>

clang:
$16 = (int *) 0x404034 <dataglobal8>

However, since the important part of this test doesn't seem to be which
symbol is linked, but rather if GDB is correctly increasing the
address. This test was changed to actually measure address changes,
instead of assuming the ordering and naming of symbols.

Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
---
 gdb/testsuite/gdb.base/nodebug.exp | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp
index 68a21eb07dd..1deed596095 100644
--- a/gdb/testsuite/gdb.base/nodebug.exp
+++ b/gdb/testsuite/gdb.base/nodebug.exp
@@ -170,6 +170,7 @@ if [nodebug_runto inner] then {
     set unk_type_re "has unknown type.*to its declared type"
     set ptr_math_re "Cannot perform pointer math on incomplete type \"$data_var_type\", try casting to a known type, or void \\*\\."
     set not_mem_re "Attempt to take address of value not located in memory\\."
+    set any_label_regexp "<\[^>\]+>"
 
     set dataglobal_unk_re "dataglobal.*$unk_type_re"
 
@@ -183,7 +184,7 @@ if [nodebug_runto inner] then {
 	{"dataglobal + 1"		""   $dataglobal_unk_re					$dataglobal_unk_re}
 	{"&dataglobal"			""   "\\($data_var_type \\*\\) $hex <dataglobal>"	" = $data_var_type \\*"}
 	{"&dataglobal + 1"		""   $ptr_math_re					$ptr_math_re}
-	{"(int *) &dataglobal + 1"	""   " = \\(int \\*\\) $hex <datalocal>"		"int \\*"}
+	{"(int *) &dataglobal + 1"	""   " = \\(int \\*\\) $hex $any_label_regexp"		"int \\*"}
 	{"&(int) dataglobal + 1"	""   $not_mem_re					$not_mem_re}
 	{"&dataglobal, &dataglobal"	""   "\\($data_var_type \\*\\) $hex <dataglobal>"	" = $data_var_type \\*"}
 	{"*dataglobal"			""   $dataglobal_unk_re					$dataglobal_unk_re}
@@ -214,7 +215,14 @@ if [nodebug_runto inner] then {
 	gdb_test "whatis $exp" $whatis
 	gdb_test "ptype $exp" $whatis
     }
-    
+
+    # Check that pointer arithmetic works as expected.
+    set addr1 [get_hexadecimal_valueof "&dataglobal" "*UNKNOWN*"]
+    set addr2 [get_hexadecimal_valueof "(int *) &dataglobal + 1" "*UNKNOWN*"]
+    set offset [expr $addr2 - $addr1]
+    set int_size [get_integer_valueof "sizeof (int)" "*UNKNOWN*"]
+    gdb_assert { $offset == $int_size }
+
     # The only symbol xcoff puts out for statics is for the TOC entry.
     # Possible, but hairy, for gdb to deal.  Right now it doesn't, it
     # doesn't know the variables exist at all.
-- 
2.31.1

Re: [PATCH v4 04/15] gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> Clang organizes the variables differently to gcc in the original version
> of this code, leading to the following differences when testing
> p (int*) &dataglobal + 1
>
> gcc:
> $16 = (int *) 0x404034 <datalocal>
>
> clang:
> $16 = (int *) 0x404034 <dataglobal8>
>
> However, since the important part of this test doesn't seem to be which
> symbol is linked, but rather if GDB is correctly increasing the
> address. This test was changed to actually measure address changes,
> instead of assuming the ordering and naming of symbols.
>
> Co-Authored-By: Andrew Burgess <aburgess@redhat.com>

This looks good.  I think this patch can be merged.

Thanks,
Andrew


> ---
>  gdb/testsuite/gdb.base/nodebug.exp | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp
> index 68a21eb07dd..1deed596095 100644
> --- a/gdb/testsuite/gdb.base/nodebug.exp
> +++ b/gdb/testsuite/gdb.base/nodebug.exp
> @@ -170,6 +170,7 @@ if [nodebug_runto inner] then {
>      set unk_type_re "has unknown type.*to its declared type"
>      set ptr_math_re "Cannot perform pointer math on incomplete type \"$data_var_type\", try casting to a known type, or void \\*\\."
>      set not_mem_re "Attempt to take address of value not located in memory\\."
> +    set any_label_regexp "<\[^>\]+>"
>  
>      set dataglobal_unk_re "dataglobal.*$unk_type_re"
>  
> @@ -183,7 +184,7 @@ if [nodebug_runto inner] then {
>  	{"dataglobal + 1"		""   $dataglobal_unk_re					$dataglobal_unk_re}
>  	{"&dataglobal"			""   "\\($data_var_type \\*\\) $hex <dataglobal>"	" = $data_var_type \\*"}
>  	{"&dataglobal + 1"		""   $ptr_math_re					$ptr_math_re}
> -	{"(int *) &dataglobal + 1"	""   " = \\(int \\*\\) $hex <datalocal>"		"int \\*"}
> +	{"(int *) &dataglobal + 1"	""   " = \\(int \\*\\) $hex $any_label_regexp"		"int \\*"}
>  	{"&(int) dataglobal + 1"	""   $not_mem_re					$not_mem_re}
>  	{"&dataglobal, &dataglobal"	""   "\\($data_var_type \\*\\) $hex <dataglobal>"	" = $data_var_type \\*"}
>  	{"*dataglobal"			""   $dataglobal_unk_re					$dataglobal_unk_re}
> @@ -214,7 +215,14 @@ if [nodebug_runto inner] then {
>  	gdb_test "whatis $exp" $whatis
>  	gdb_test "ptype $exp" $whatis
>      }
> -    
> +
> +    # Check that pointer arithmetic works as expected.
> +    set addr1 [get_hexadecimal_valueof "&dataglobal" "*UNKNOWN*"]
> +    set addr2 [get_hexadecimal_valueof "(int *) &dataglobal + 1" "*UNKNOWN*"]
> +    set offset [expr $addr2 - $addr1]
> +    set int_size [get_integer_valueof "sizeof (int)" "*UNKNOWN*"]
> +    gdb_assert { $offset == $int_size }
> +
>      # The only symbol xcoff puts out for statics is for the TOC entry.
>      # Possible, but hairy, for gdb to deal.  Right now it doesn't, it
>      # doesn't know the variables exist at all.
> -- 
> 2.31.1

Re: [PATCH v4 04/15] gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang

[Bruno Larsen]

Thanks, pushed!

Cheers,
Bruno

On 12/09/2022 11:08, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> Clang organizes the variables differently to gcc in the original version
>> of this code, leading to the following differences when testing
>> p (int*) &dataglobal + 1
>>
>> gcc:
>> $16 = (int *) 0x404034 <datalocal>
>>
>> clang:
>> $16 = (int *) 0x404034 <dataglobal8>
>>
>> However, since the important part of this test doesn't seem to be which
>> symbol is linked, but rather if GDB is correctly increasing the
>> address. This test was changed to actually measure address changes,
>> instead of assuming the ordering and naming of symbols.
>>
>> Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
> This looks good.  I think this patch can be merged.
>
> Thanks,
> Andrew
>
>
>> ---
>>   gdb/testsuite/gdb.base/nodebug.exp | 12 ++++++++++--
>>   1 file changed, 10 insertions(+), 2 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/nodebug.exp b/gdb/testsuite/gdb.base/nodebug.exp
>> index 68a21eb07dd..1deed596095 100644
>> --- a/gdb/testsuite/gdb.base/nodebug.exp
>> +++ b/gdb/testsuite/gdb.base/nodebug.exp
>> @@ -170,6 +170,7 @@ if [nodebug_runto inner] then {
>>       set unk_type_re "has unknown type.*to its declared type"
>>       set ptr_math_re "Cannot perform pointer math on incomplete type \"$data_var_type\", try casting to a known type, or void \\*\\."
>>       set not_mem_re "Attempt to take address of value not located in memory\\."
>> +    set any_label_regexp "<\[^>\]+>"
>>   
>>       set dataglobal_unk_re "dataglobal.*$unk_type_re"
>>   
>> @@ -183,7 +184,7 @@ if [nodebug_runto inner] then {
>>   	{"dataglobal + 1"		""   $dataglobal_unk_re					$dataglobal_unk_re}
>>   	{"&dataglobal"			""   "\\($data_var_type \\*\\) $hex <dataglobal>"	" = $data_var_type \\*"}
>>   	{"&dataglobal + 1"		""   $ptr_math_re					$ptr_math_re}
>> -	{"(int *) &dataglobal + 1"	""   " = \\(int \\*\\) $hex <datalocal>"		"int \\*"}
>> +	{"(int *) &dataglobal + 1"	""   " = \\(int \\*\\) $hex $any_label_regexp"		"int \\*"}
>>   	{"&(int) dataglobal + 1"	""   $not_mem_re					$not_mem_re}
>>   	{"&dataglobal, &dataglobal"	""   "\\($data_var_type \\*\\) $hex <dataglobal>"	" = $data_var_type \\*"}
>>   	{"*dataglobal"			""   $dataglobal_unk_re					$dataglobal_unk_re}
>> @@ -214,7 +215,14 @@ if [nodebug_runto inner] then {
>>   	gdb_test "whatis $exp" $whatis
>>   	gdb_test "ptype $exp" $whatis
>>       }
>> -
>> +
>> +    # Check that pointer arithmetic works as expected.
>> +    set addr1 [get_hexadecimal_valueof "&dataglobal" "*UNKNOWN*"]
>> +    set addr2 [get_hexadecimal_valueof "(int *) &dataglobal + 1" "*UNKNOWN*"]
>> +    set offset [expr $addr2 - $addr1]
>> +    set int_size [get_integer_valueof "sizeof (int)" "*UNKNOWN*"]
>> +    gdb_assert { $offset == $int_size }
>> +
>>       # The only symbol xcoff puts out for statics is for the TOC entry.
>>       # Possible, but hairy, for gdb to deal.  Right now it doesn't, it
>>       # doesn't know the variables exist at all.
>> -- 
>> 2.31.1

[PATCH v4 05/15] update gdb.base/info-program.exp to not fail with clang

[Bruno Larsen]

The updated test specifically mentions that it doesn't care where the
program stops, however it was still testing for something.  With this
correction, the test works even if the compiler doesn't emit line table
entries for the function epilogue.
---
 gdb/testsuite/gdb.base/info-program.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/info-program.exp b/gdb/testsuite/gdb.base/info-program.exp
index facc13efa2f..f652cfbf426 100644
--- a/gdb/testsuite/gdb.base/info-program.exp
+++ b/gdb/testsuite/gdb.base/info-program.exp
@@ -28,7 +28,7 @@ gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped at breakpoint $
 
 # We don't really care where this step lands, so long as it gets
 # the inferior pushed off the breakpoint it's currently on...
-gdb_test "next" "$decimal\t.*" "step before info program"
+gdb_test "next" ".*" "step before info program"
 
 gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped after being stepped\.\r\nType \"info stack\" or \"info registers\" for more information\." \
     "info program after next"
-- 
2.31.1

Re: [PATCH v4 05/15] update gdb.base/info-program.exp to not fail with clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> The updated test specifically mentions that it doesn't care where the

I think this sentence makes more sense without 'updated'.

> program stops, however it was still testing for something.  With this

s/something/a specific location/ ?

I think it might be worth adding a sentence before the 'With this...'.

  The clang compiler emits different line information for function
  epilogue, and so GDB reports the stop at a different location.

Then finish with: 'With this patch the test works even with clang.'

> correction, the test works even if the compiler doesn't emit line table
> entries for the function epilogue.
> ---
>  gdb/testsuite/gdb.base/info-program.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/info-program.exp b/gdb/testsuite/gdb.base/info-program.exp
> index facc13efa2f..f652cfbf426 100644
> --- a/gdb/testsuite/gdb.base/info-program.exp
> +++ b/gdb/testsuite/gdb.base/info-program.exp
> @@ -28,7 +28,7 @@ gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped at breakpoint $
>  
>  # We don't really care where this step lands, so long as it gets
>  # the inferior pushed off the breakpoint it's currently on...
> -gdb_test "next" "$decimal\t.*" "step before info program"
> +gdb_test "next" ".*" "step before info program"

I think I'd be tempted to rewrite this comment.  Currently we say that
we don't care where we stop, just so long as we stop somewhere else.
The test used to ensure that we did indeed stop somewhere else.  The
problem is with clang, that somewhere else might be different.  But, but
using '.*' as a pattern, we're not actually checking that we've moved at
all.

However, I don't think that actually matters, based on the next thing we
do, I think this comment would do:

  # We don't really care where this `next` lands, so long as GDB reports
  # that the inferior stopped due to a step in the subsequent test.

With these changes I think this patch can be merged.

Thanks,
Andrew

>  
>  gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped after being stepped\.\r\nType \"info stack\" or \"info registers\" for more information\." \
>      "info program after next"
> -- 
> 2.31.1

Re: [PATCH v4 05/15] update gdb.base/info-program.exp to not fail with clang

[Bruno Larsen]

Thanks, I applied your comments and pushed!

Cheers,
Bruno

On 12/09/2022 11:34, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> The updated test specifically mentions that it doesn't care where the
> I think this sentence makes more sense without 'updated'.
>
>> program stops, however it was still testing for something.  With this
> s/something/a specific location/ ?
>
> I think it might be worth adding a sentence before the 'With this...'.
>
>    The clang compiler emits different line information for function
>    epilogue, and so GDB reports the stop at a different location.
>
> Then finish with: 'With this patch the test works even with clang.'
>
>> correction, the test works even if the compiler doesn't emit line table
>> entries for the function epilogue.
>> ---
>>   gdb/testsuite/gdb.base/info-program.exp | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/info-program.exp b/gdb/testsuite/gdb.base/info-program.exp
>> index facc13efa2f..f652cfbf426 100644
>> --- a/gdb/testsuite/gdb.base/info-program.exp
>> +++ b/gdb/testsuite/gdb.base/info-program.exp
>> @@ -28,7 +28,7 @@ gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped at breakpoint $
>>   
>>   # We don't really care where this step lands, so long as it gets
>>   # the inferior pushed off the breakpoint it's currently on...
>> -gdb_test "next" "$decimal\t.*" "step before info program"
>> +gdb_test "next" ".*" "step before info program"
> I think I'd be tempted to rewrite this comment.  Currently we say that
> we don't care where we stop, just so long as we stop somewhere else.
> The test used to ensure that we did indeed stop somewhere else.  The
> problem is with clang, that somewhere else might be different.  But, but
> using '.*' as a pattern, we're not actually checking that we've moved at
> all.
>
> However, I don't think that actually matters, based on the next thing we
> do, I think this comment would do:
>
>    # We don't really care where this `next` lands, so long as GDB reports
>    # that the inferior stopped due to a step in the subsequent test.
>
> With these changes I think this patch can be merged.
>
> Thanks,
> Andrew
>
>>   
>>   gdb_test "info program" "Program stopped at $hex\.\r\nIt stopped after being stepped\.\r\nType \"info stack\" or \"info registers\" for more information\." \
>>       "info program after next"
>> -- 
>> 2.31.1

[PATCH v4 06/15] fix gdb.base/access-mem-running.exp for clang testing

[Bruno Larsen]

Clang was optimizing global_var away because it was not being used
anywhere. this commit fixes that by adding the attribute used it.
---
 gdb/testsuite/gdb.base/access-mem-running.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/access-mem-running.c b/gdb/testsuite/gdb.base/access-mem-running.c
index 6335f1bf199..cff6f0da820 100644
--- a/gdb/testsuite/gdb.base/access-mem-running.c
+++ b/gdb/testsuite/gdb.base/access-mem-running.c
@@ -19,7 +19,7 @@
 
 static unsigned int global_counter = 1;
 
-static volatile unsigned int global_var = 123;
+static volatile unsigned int __attribute__((used)) global_var = 123;
 
 static void
 maybe_stop_here ()
-- 
2.31.1

Re: [PATCH v4 06/15] fix gdb.base/access-mem-running.exp for clang testing

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> Clang was optimizing global_var away because it was not being used
> anywhere. this commit fixes that by adding the attribute used it.
> ---
>  gdb/testsuite/gdb.base/access-mem-running.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/access-mem-running.c b/gdb/testsuite/gdb.base/access-mem-running.c
> index 6335f1bf199..cff6f0da820 100644
> --- a/gdb/testsuite/gdb.base/access-mem-running.c
> +++ b/gdb/testsuite/gdb.base/access-mem-running.c
> @@ -19,7 +19,7 @@
>  
>  static unsigned int global_counter = 1;
>  
> -static volatile unsigned int global_var = 123;
> +static volatile unsigned int __attribute__((used)) global_var = 123;
>  
>  static void
>  maybe_stop_here ()

LGTM.  Feel free to merge this.

Thanks,
Andrew

Re: [PATCH v4 06/15] fix gdb.base/access-mem-running.exp for clang testing

[Bruno Larsen]

thanks, pushed!

Cheers,
Bruno

On 12/09/2022 11:41, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> Clang was optimizing global_var away because it was not being used
>> anywhere. this commit fixes that by adding the attribute used it.
>> ---
>>   gdb/testsuite/gdb.base/access-mem-running.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/access-mem-running.c b/gdb/testsuite/gdb.base/access-mem-running.c
>> index 6335f1bf199..cff6f0da820 100644
>> --- a/gdb/testsuite/gdb.base/access-mem-running.c
>> +++ b/gdb/testsuite/gdb.base/access-mem-running.c
>> @@ -19,7 +19,7 @@
>>   
>>   static unsigned int global_counter = 1;
>>   
>> -static volatile unsigned int global_var = 123;
>> +static volatile unsigned int __attribute__((used)) global_var = 123;
>>   
>>   static void
>>   maybe_stop_here ()
> LGTM.  Feel free to merge this.
>
> Thanks,
> Andrew
>

[PATCH v4 07/15] Fix gdb.base/call-ar-st to work with Clang

[Bruno Larsen]

When running gdb.base/call-ar-st.exp against Clang, we see one FAIL,
like so:

 print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa
 ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
 274       print_int_array(array_i);     /* -step1- */
 (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays

With GCC we instead see:

 print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
 274       print_int_array(array_i);     /* -step1- */
 (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays

The difference is that with Clang we get:

 array_i=<main.integer_array>, ...

instead of

 array_i = <integer_array>, ...

These symbols are local static variables, and "main" is the name of
the function they are defined in.  GCC instead appends a sequence
number to the linkage name:

 $ nm -A call-ar-st.gcc | grep integer_
 call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968

 $ nm -A call-ar-st.clang | grep integer_
 call-ar-st:00000000004061a0 b main.integer_array

This commit changes the testcase to accept both outputs, as they are
functionally identical.

Co-Authored-By: Pedro Alves <pedro@palves.net>
Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4
---
 gdb/testsuite/gdb.base/call-ar-st.exp | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/call-ar-st.exp b/gdb/testsuite/gdb.base/call-ar-st.exp
index 7c80ec7c0b8..2da438ccd96 100644
--- a/gdb/testsuite/gdb.base/call-ar-st.exp
+++ b/gdb/testsuite/gdb.base/call-ar-st.exp
@@ -147,10 +147,21 @@ if {!$skip_float_test && \
     gdb_test "continue" ".*" ""
 }
 
+# Return a regexp that matches the linkage name of SYM, assuming SYM
+# is a local static variable inside the main function.
+proc main_static_local_re {sym} {
+    # Clang prepends the function name + '.'.
+    return "(main\\.)?${sym}"
+}
+
 #step
 set stop_line [gdb_get_line_number "-step1-"]
 gdb_test "step" \
-    "print_all_arrays \\(array_i=<integer_array.*>, array_c=<char_array.*> .ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa., array_f=<float_array.*>, array_d=<double_array.*>\\) at .*$srcfile:$stop_line\[ \t\r\n\]+$stop_line.*print_int_array\\(array_i\\);.*" \
+    "print_all_arrays \\(array_i=<[main_static_local_re integer_array]>,\
+			 array_c=<[main_static_local_re char_array]> .ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa.,\
+			 array_f=<[main_static_local_re float_array]>,\
+			 array_d=<[main_static_local_re double_array]>\\)\
+			 at .*$srcfile:$stop_line\[ \t\r\n\]+$stop_line.*print_int_array\\(array_i\\);.*" \
     "step inside print_all_arrays"
 
 #step -over
-- 
2.31.1

Re: [PATCH v4 07/15] Fix gdb.base/call-ar-st to work with Clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> When running gdb.base/call-ar-st.exp against Clang, we see one FAIL,
> like so:
>
>  print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa
>  ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
>  274       print_int_array(array_i);     /* -step1- */
>  (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays
>
> With GCC we instead see:
>
>  print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
>  274       print_int_array(array_i);     /* -step1- */
>  (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays
>
> The difference is that with Clang we get:
>
>  array_i=<main.integer_array>, ...
>
> instead of
>
>  array_i = <integer_array>, ...
>
> These symbols are local static variables, and "main" is the name of
> the function they are defined in.  GCC instead appends a sequence
> number to the linkage name:
>
>  $ nm -A call-ar-st.gcc | grep integer_
>  call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968
>
>  $ nm -A call-ar-st.clang | grep integer_
>  call-ar-st:00000000004061a0 b main.integer_array
>
> This commit changes the testcase to accept both outputs, as they are
> functionally identical.
>
> Co-Authored-By: Pedro Alves <pedro@palves.net>
> Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4

LGTM.  I think this could be merged.

Thanks,
Andrew


> ---
>  gdb/testsuite/gdb.base/call-ar-st.exp | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/call-ar-st.exp b/gdb/testsuite/gdb.base/call-ar-st.exp
> index 7c80ec7c0b8..2da438ccd96 100644
> --- a/gdb/testsuite/gdb.base/call-ar-st.exp
> +++ b/gdb/testsuite/gdb.base/call-ar-st.exp
> @@ -147,10 +147,21 @@ if {!$skip_float_test && \
>      gdb_test "continue" ".*" ""
>  }
>  
> +# Return a regexp that matches the linkage name of SYM, assuming SYM
> +# is a local static variable inside the main function.
> +proc main_static_local_re {sym} {
> +    # Clang prepends the function name + '.'.
> +    return "(main\\.)?${sym}"
> +}
> +
>  #step
>  set stop_line [gdb_get_line_number "-step1-"]
>  gdb_test "step" \
> -    "print_all_arrays \\(array_i=<integer_array.*>, array_c=<char_array.*> .ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa., array_f=<float_array.*>, array_d=<double_array.*>\\) at .*$srcfile:$stop_line\[ \t\r\n\]+$stop_line.*print_int_array\\(array_i\\);.*" \
> +    "print_all_arrays \\(array_i=<[main_static_local_re integer_array]>,\
> +			 array_c=<[main_static_local_re char_array]> .ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa.,\
> +			 array_f=<[main_static_local_re float_array]>,\
> +			 array_d=<[main_static_local_re double_array]>\\)\
> +			 at .*$srcfile:$stop_line\[ \t\r\n\]+$stop_line.*print_int_array\\(array_i\\);.*" \
>      "step inside print_all_arrays"
>  
>  #step -over
> -- 
> 2.31.1

Re: [PATCH v4 07/15] Fix gdb.base/call-ar-st to work with Clang

[Bruno Larsen]

thanks, pushed!

Cheers,
Bruno

On 12/09/2022 12:30, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> When running gdb.base/call-ar-st.exp against Clang, we see one FAIL,
>> like so:
>>
>>   print_all_arrays (array_i=<main.integer_array>, array_c=<main.char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa
>>   ZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<main.float_array>, array_d=<main.double_array>) at ../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
>>   274       print_int_array(array_i);     /* -step1- */
>>   (gdb) FAIL: gdb.base/call-ar-st.exp: step inside print_all_arrays
>>
>> With GCC we instead see:
>>
>>   print_all_arrays (array_i=<integer_array>, array_c=<char_array> "ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa", array_f=<float_array>, array_d=<double_array>) at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/call-ar-st.c:274
>>   274       print_int_array(array_i);     /* -step1- */
>>   (gdb) PASS: gdb.base/call-ar-st.exp: step inside print_all_arrays
>>
>> The difference is that with Clang we get:
>>
>>   array_i=<main.integer_array>, ...
>>
>> instead of
>>
>>   array_i = <integer_array>, ...
>>
>> These symbols are local static variables, and "main" is the name of
>> the function they are defined in.  GCC instead appends a sequence
>> number to the linkage name:
>>
>>   $ nm -A call-ar-st.gcc | grep integer_
>>   call-ar-st/call-ar-st:00000000000061a0 b integer_array.3968
>>
>>   $ nm -A call-ar-st.clang | grep integer_
>>   call-ar-st:00000000004061a0 b main.integer_array
>>
>> This commit changes the testcase to accept both outputs, as they are
>> functionally identical.
>>
>> Co-Authored-By: Pedro Alves <pedro@palves.net>
>> Change-Id: Iaf2ccdb9d5996e0268ed12f595a6e04b368bfcb4
> LGTM.  I think this could be merged.
>
> Thanks,
> Andrew
>
>
>> ---
>>   gdb/testsuite/gdb.base/call-ar-st.exp | 13 ++++++++++++-
>>   1 file changed, 12 insertions(+), 1 deletion(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/call-ar-st.exp b/gdb/testsuite/gdb.base/call-ar-st.exp
>> index 7c80ec7c0b8..2da438ccd96 100644
>> --- a/gdb/testsuite/gdb.base/call-ar-st.exp
>> +++ b/gdb/testsuite/gdb.base/call-ar-st.exp
>> @@ -147,10 +147,21 @@ if {!$skip_float_test && \
>>       gdb_test "continue" ".*" ""
>>   }
>>   
>> +# Return a regexp that matches the linkage name of SYM, assuming SYM
>> +# is a local static variable inside the main function.
>> +proc main_static_local_re {sym} {
>> +    # Clang prepends the function name + '.'.
>> +    return "(main\\.)?${sym}"
>> +}
>> +
>>   #step
>>   set stop_line [gdb_get_line_number "-step1-"]
>>   gdb_test "step" \
>> -    "print_all_arrays \\(array_i=<integer_array.*>, array_c=<char_array.*> .ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa., array_f=<float_array.*>, array_d=<double_array.*>\\) at .*$srcfile:$stop_line\[ \t\r\n\]+$stop_line.*print_int_array\\(array_i\\);.*" \
>> +    "print_all_arrays \\(array_i=<[main_static_local_re integer_array]>,\
>> +			 array_c=<[main_static_local_re char_array]> .ZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZaZa.,\
>> +			 array_f=<[main_static_local_re float_array]>,\
>> +			 array_d=<[main_static_local_re double_array]>\\)\
>> +			 at .*$srcfile:$stop_line\[ \t\r\n\]+$stop_line.*print_int_array\\(array_i\\);.*" \
>>       "step inside print_all_arrays"
>>   
>>   #step -over
>> -- 
>> 2.31.1

[PATCH v4 08/15] add xfails to gdb.base/complex-parts.exp when testing with clang

[Bruno Larsen]

clang doesn't add encoding to the name of complex variables, only says
that the type name is complex, making the relevant tests fail.
This patch adds the xfails to the tests that expect the variable name to
include it.
---
 gdb/testsuite/gdb.base/complex-parts.exp | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gdb/testsuite/gdb.base/complex-parts.exp b/gdb/testsuite/gdb.base/complex-parts.exp
index e67fd482268..7fa94c72cd4 100644
--- a/gdb/testsuite/gdb.base/complex-parts.exp
+++ b/gdb/testsuite/gdb.base/complex-parts.exp
@@ -30,8 +30,13 @@ gdb_test "p z1" " = 1.5 \\+ 4.5i"
 gdb_test "p z2" " = 2.5 \\+ -5.5i"
 gdb_test "p z3" " = 3.5 \\+ 6.5i"
 
+# The following 3 tests are broken for Clang.
+# More info at https://github.com/llvm/llvm-project/issues/52996.
+if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
 gdb_test "ptype z1" " = complex double"
+if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
 gdb_test "ptype z2" " = complex float"
+if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
 gdb_test "ptype z3" " = complex long double"
 
 with_test_prefix "double imaginary" {
-- 
2.31.1

Re: [PATCH v4 08/15] add xfails to gdb.base/complex-parts.exp when testing with clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> clang doesn't add encoding to the name of complex variables, only says
> that the type name is complex, making the relevant tests fail.
> This patch adds the xfails to the tests that expect the variable name to
> include it.
> ---
>  gdb/testsuite/gdb.base/complex-parts.exp | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.base/complex-parts.exp b/gdb/testsuite/gdb.base/complex-parts.exp
> index e67fd482268..7fa94c72cd4 100644
> --- a/gdb/testsuite/gdb.base/complex-parts.exp
> +++ b/gdb/testsuite/gdb.base/complex-parts.exp
> @@ -30,8 +30,13 @@ gdb_test "p z1" " = 1.5 \\+ 4.5i"
>  gdb_test "p z2" " = 2.5 \\+ -5.5i"
>  gdb_test "p z3" " = 3.5 \\+ 6.5i"
>  
> +# The following 3 tests are broken for Clang.
> +# More info at https://github.com/llvm/llvm-project/issues/52996.
> +if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
>  gdb_test "ptype z1" " = complex double"
> +if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
>  gdb_test "ptype z2" " = complex float"
> +if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
>  gdb_test "ptype z3" " = complex long double"
>  
>  with_test_prefix "double imaginary" {

LGTM.  Please go ahead and apply.

Thanks,
Andrew

Re: [PATCH v4 08/15] add xfails to gdb.base/complex-parts.exp when testing with clang

[Bruno Larsen]

thanks, pushed!

Cheers,
Bruno

On 12/09/2022 12:49, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> clang doesn't add encoding to the name of complex variables, only says
>> that the type name is complex, making the relevant tests fail.
>> This patch adds the xfails to the tests that expect the variable name to
>> include it.
>> ---
>>   gdb/testsuite/gdb.base/complex-parts.exp | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/gdb/testsuite/gdb.base/complex-parts.exp b/gdb/testsuite/gdb.base/complex-parts.exp
>> index e67fd482268..7fa94c72cd4 100644
>> --- a/gdb/testsuite/gdb.base/complex-parts.exp
>> +++ b/gdb/testsuite/gdb.base/complex-parts.exp
>> @@ -30,8 +30,13 @@ gdb_test "p z1" " = 1.5 \\+ 4.5i"
>>   gdb_test "p z2" " = 2.5 \\+ -5.5i"
>>   gdb_test "p z3" " = 3.5 \\+ 6.5i"
>>   
>> +# The following 3 tests are broken for Clang.
>> +# More info at https://github.com/llvm/llvm-project/issues/52996.
>> +if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
>>   gdb_test "ptype z1" " = complex double"
>> +if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
>>   gdb_test "ptype z2" " = complex float"
>> +if {[test_compiler_info clang-*-*]} { setup_xfail *-*-* }
>>   gdb_test "ptype z3" " = complex long double"
>>   
>>   with_test_prefix "double imaginary" {
> LGTM.  Please go ahead and apply.
>
> Thanks,
> Andrew
>

[PATCH v4 09/15] gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang

[Bruno Larsen]

Because Clang's -O0 is not as unoptimized as gcc's, one of the functions
of gdb.base/msym-bp-shl was being optimized away, making the entire test
fail. A lot of the test fail like so:

(gdb) break foo
Breakpoint 1 at 0x401030
(gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
info breakpoint
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   0x0000000000401030 <foo@plt>
(gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint

As the test expects 2 breakpoints to be placed. This can't be easily fixed
by adding __attribute__ ((used)) to the function, since Clang will still
optimize away the function. Because of this, the test is skipped when
the it detects that Clang is being used
---
 gdb/testsuite/gdb.base/msym-bp-shl.exp | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/gdb/testsuite/gdb.base/msym-bp-shl.exp b/gdb/testsuite/gdb.base/msym-bp-shl.exp
index 42adcb191dd..dd7d05bab52 100644
--- a/gdb/testsuite/gdb.base/msym-bp-shl.exp
+++ b/gdb/testsuite/gdb.base/msym-bp-shl.exp
@@ -22,6 +22,14 @@ if {[skip_shlib_tests]} {
     return 0
 }
 
+# Clang will optimize away the static foo, regardless of using
+# __attribute__((used)), so we'll always get a single breakpoint
+# making this test useless
+if {[test_compiler_info {clang-*-*}]} {
+    untested "Clang optimizes away one of the functions"
+    return
+}
+
 standard_testfile msym-bp-shl-main.c msym-bp-shl-main-2.c msym-bp-shl-lib.c
 set srcfile ${srcdir}/${subdir}/${srcfile}
 set srcfile2 ${srcdir}/${subdir}/${srcfile2}
-- 
2.31.1

Re: [PATCH v4 09/15] gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> Because Clang's -O0 is not as unoptimized as gcc's, one of the functions
> of gdb.base/msym-bp-shl was being optimized away, making the entire test
> fail. A lot of the test fail like so:
>
> (gdb) break foo
> Breakpoint 1 at 0x401030
> (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
> info breakpoint
> Num     Type           Disp Enb Address            What
> 1       breakpoint     keep y   0x0000000000401030 <foo@plt>
> (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
>
> As the test expects 2 breakpoints to be placed. This can't be easily fixed
> by adding __attribute__ ((used)) to the function, since Clang will still
> optimize away the function. Because of this, the test is skipped when
> the it detects that Clang is being used

In this mail:

  https://sourceware.org/pipermail/gdb-patches/2022-March/187197.html

Pedro suggests using __attribute__((used)), in your follow up:

  https://sourceware.org/pipermail/gdb-patches/2022-March/187199.html

you confirm that this approach works for you.  I just checked, and the
attribute patch Pedro suggests makes the test pass for me with Clang.

Should this patch have been updated?  If not, what changed?

Thanks,
Andrew

> ---
>  gdb/testsuite/gdb.base/msym-bp-shl.exp | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.base/msym-bp-shl.exp b/gdb/testsuite/gdb.base/msym-bp-shl.exp
> index 42adcb191dd..dd7d05bab52 100644
> --- a/gdb/testsuite/gdb.base/msym-bp-shl.exp
> +++ b/gdb/testsuite/gdb.base/msym-bp-shl.exp
> @@ -22,6 +22,14 @@ if {[skip_shlib_tests]} {
>      return 0
>  }
>  
> +# Clang will optimize away the static foo, regardless of using
> +# __attribute__((used)), so we'll always get a single breakpoint
> +# making this test useless
> +if {[test_compiler_info {clang-*-*}]} {
> +    untested "Clang optimizes away one of the functions"
> +    return
> +}
> +
>  standard_testfile msym-bp-shl-main.c msym-bp-shl-main-2.c msym-bp-shl-lib.c
>  set srcfile ${srcdir}/${subdir}/${srcfile}
>  set srcfile2 ${srcdir}/${subdir}/${srcfile2}
> -- 
> 2.31.1

Re: [PATCH v4 09/15] gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang

[Bruno Larsen]

On 12/09/2022 12:58, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> Because Clang's -O0 is not as unoptimized as gcc's, one of the functions
>> of gdb.base/msym-bp-shl was being optimized away, making the entire test
>> fail. A lot of the test fail like so:
>>
>> (gdb) break foo
>> Breakpoint 1 at 0x401030
>> (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: break foo
>> info breakpoint
>> Num     Type           Disp Enb Address            What
>> 1       breakpoint     keep y   0x0000000000401030 <foo@plt>
>> (gdb) FAIL: gdb.base/msym-bp-shl.exp: debug=0: before run: info breakpoint
>>
>> As the test expects 2 breakpoints to be placed. This can't be easily fixed
>> by adding __attribute__ ((used)) to the function, since Clang will still
>> optimize away the function. Because of this, the test is skipped when
>> the it detects that Clang is being used
> In this mail:
>
>    https://sourceware.org/pipermail/gdb-patches/2022-March/187197.html
>
> Pedro suggests using __attribute__((used)), in your follow up:
>
>    https://sourceware.org/pipermail/gdb-patches/2022-March/187199.html
>
> you confirm that this approach works for you.  I just checked, and the
> attribute patch Pedro suggests makes the test pass for me with Clang.
>
> Should this patch have been updated?  If not, what changed?

This patch should have been updated, sorry.

--
Cheers,
Bruno

>
> Thanks,
> Andrew
>
>> ---
>>   gdb/testsuite/gdb.base/msym-bp-shl.exp | 8 ++++++++
>>   1 file changed, 8 insertions(+)
>>
>> diff --git a/gdb/testsuite/gdb.base/msym-bp-shl.exp b/gdb/testsuite/gdb.base/msym-bp-shl.exp
>> index 42adcb191dd..dd7d05bab52 100644
>> --- a/gdb/testsuite/gdb.base/msym-bp-shl.exp
>> +++ b/gdb/testsuite/gdb.base/msym-bp-shl.exp
>> @@ -22,6 +22,14 @@ if {[skip_shlib_tests]} {
>>       return 0
>>   }
>>   
>> +# Clang will optimize away the static foo, regardless of using
>> +# __attribute__((used)), so we'll always get a single breakpoint
>> +# making this test useless
>> +if {[test_compiler_info {clang-*-*}]} {
>> +    untested "Clang optimizes away one of the functions"
>> +    return
>> +}
>> +
>>   standard_testfile msym-bp-shl-main.c msym-bp-shl-main-2.c msym-bp-shl-lib.c
>>   set srcfile ${srcdir}/${subdir}/${srcfile}
>>   set srcfile2 ${srcdir}/${subdir}/${srcfile2}
>> -- 
>> 2.31.1

[PATCH v4 10/15] explicitly test for stderr in gdb.base/dprintf.exp

[Bruno Larsen]

Not all compilers add stderr debug information when compiling a
program. Clang, for instance, prefers to add nothing from standard
libraries and let an external debug package have this information.
Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
use dprintf as a call to fprintf(stderrr, ...), like this:

 (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
 continue
 Continuing.
 kickoff 1234
 also to stderr 1234
 'stderr' has unknown type; cast it to its declared type
 (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)

To avoid this false positive, we explicitly test to see if
the compiler has added information about stderr at all, and abort
testing dprintf as an fprintf call if it is unavailable.
---
 gdb/testsuite/gdb.base/dprintf.exp | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/gdb/testsuite/gdb.base/dprintf.exp b/gdb/testsuite/gdb.base/dprintf.exp
index 0b209c02a62..e214531f6dc 100644
--- a/gdb/testsuite/gdb.base/dprintf.exp
+++ b/gdb/testsuite/gdb.base/dprintf.exp
@@ -111,6 +111,16 @@ proc test_call {} {
 	test_dprintf "At foo entry.*arg=1235, g=2222\r\n" "2nd dprintf"
     }
 
+    gdb_test_multiple "print stderr" "stderr symbol check" {
+	-re "\\'stderr\\' has unknown type.*" {
+	    untested "No information available for stderr, exiting early"
+	    return
+	}
+	-re "\\\$1.*" {
+	    pass "stderr is available"
+	}
+    }
+
     with_test_prefix "fprintf" {
 	restart
 
-- 
2.31.1

Re: [PATCH v4 10/15] explicitly test for stderr in gdb.base/dprintf.exp

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> Not all compilers add stderr debug information when compiling a
> program. Clang, for instance, prefers to add nothing from standard
> libraries and let an external debug package have this information.
> Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
> use dprintf as a call to fprintf(stderrr, ...), like this:
>
>  (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
>  continue
>  Continuing.
>  kickoff 1234
>  also to stderr 1234
>  'stderr' has unknown type; cast it to its declared type
>  (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)
>
> To avoid this false positive, we explicitly test to see if
> the compiler has added information about stderr at all, and abort
> testing dprintf as an fprintf call if it is unavailable.
> ---
>  gdb/testsuite/gdb.base/dprintf.exp | 10 ++++++++++
>  1 file changed, 10 insertions(+)
>
> diff --git a/gdb/testsuite/gdb.base/dprintf.exp b/gdb/testsuite/gdb.base/dprintf.exp
> index 0b209c02a62..e214531f6dc 100644
> --- a/gdb/testsuite/gdb.base/dprintf.exp
> +++ b/gdb/testsuite/gdb.base/dprintf.exp
> @@ -111,6 +111,16 @@ proc test_call {} {
>  	test_dprintf "At foo entry.*arg=1235, g=2222\r\n" "2nd dprintf"
>      }
>  
> +    gdb_test_multiple "print stderr" "stderr symbol check" {
> +	-re "\\'stderr\\' has unknown type.*" {
> +	    untested "No information available for stderr, exiting early"
> +	    return
> +	}
> +	-re "\\\$1.*" {
> +	    pass "stderr is available"

I think this should be `pass $gdb_test_name`, but OK to commit with that
change.

Thanks,
Andrew

> +	}
> +    }
> +
>      with_test_prefix "fprintf" {
>  	restart
>  
> -- 
> 2.31.1

Re: [PATCH v4 10/15] explicitly test for stderr in gdb.base/dprintf.exp

[Bruno Larsen]

Thanks, pushed!

Cheers,
Bruno

On 12/09/2022 14:20, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> Not all compilers add stderr debug information when compiling a
>> program. Clang, for instance, prefers to add nothing from standard
>> libraries and let an external debug package have this information.
>> Because of this, gdb.base/dprintf.exp was failing when GDB attempted to
>> use dprintf as a call to fprintf(stderrr, ...), like this:
>>
>>   (gdb) PASS: gdb.base/dprintf.exp: call: fprintf: set dprintf style to call
>>   continue
>>   Continuing.
>>   kickoff 1234
>>   also to stderr 1234
>>   'stderr' has unknown type; cast it to its declared type
>>   (gdb) FAIL: gdb.base/dprintf.exp: call: fprintf: 1st dprintf (timeout)
>>
>> To avoid this false positive, we explicitly test to see if
>> the compiler has added information about stderr at all, and abort
>> testing dprintf as an fprintf call if it is unavailable.
>> ---
>>   gdb/testsuite/gdb.base/dprintf.exp | 10 ++++++++++
>>   1 file changed, 10 insertions(+)
>>
>> diff --git a/gdb/testsuite/gdb.base/dprintf.exp b/gdb/testsuite/gdb.base/dprintf.exp
>> index 0b209c02a62..e214531f6dc 100644
>> --- a/gdb/testsuite/gdb.base/dprintf.exp
>> +++ b/gdb/testsuite/gdb.base/dprintf.exp
>> @@ -111,6 +111,16 @@ proc test_call {} {
>>   	test_dprintf "At foo entry.*arg=1235, g=2222\r\n" "2nd dprintf"
>>       }
>>   
>> +    gdb_test_multiple "print stderr" "stderr symbol check" {
>> +	-re "\\'stderr\\' has unknown type.*" {
>> +	    untested "No information available for stderr, exiting early"
>> +	    return
>> +	}
>> +	-re "\\\$1.*" {
>> +	    pass "stderr is available"
> I think this should be `pass $gdb_test_name`, but OK to commit with that
> change.
>
> Thanks,
> Andrew
>
>> +	}
>> +    }
>> +
>>       with_test_prefix "fprintf" {
>>   	restart
>>   
>> -- 
>> 2.31.1

[PATCH v4 11/15] gdb/testsuite: Update gdb.base/so-impl-ld.exp

[Bruno Larsen]

gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
epilogue information and that GDB would stop in the } line.  This would
make clang tests fail like so:

 step^M
 solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
 7|__  return arg*arg;|__|___/* HERE */^M
 (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
 next^M
 main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
 22|_  return 0;^M
 (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
 next^M
 0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
 (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call

This patch changes it so solib_main has 2 lines where GDB can stop
regardless of compiler weirdness, and updates the exp file to
generically deal with unknown number of steps until leaving that
function.
---
 gdb/testsuite/gdb.base/so-impl-ld.exp | 13 ++-----------
 gdb/testsuite/gdb.base/solib1.c       |  5 +++--
 2 files changed, 5 insertions(+), 13 deletions(-)

diff --git a/gdb/testsuite/gdb.base/so-impl-ld.exp b/gdb/testsuite/gdb.base/so-impl-ld.exp
index 372b18f3915..3c5d1070a5b 100644
--- a/gdb/testsuite/gdb.base/so-impl-ld.exp
+++ b/gdb/testsuite/gdb.base/so-impl-ld.exp
@@ -56,21 +56,12 @@ gdb_test "step" "solib_main .arg=10000. at.*${libfile}.c:${decimal}.* HERE .*" \
 
 # Verify that we can step within the shlib call.
 #
-gdb_test "next" "${decimal}\[ \t\]*\}.* STEP .*" "step in solib call"
+gdb_test "next" "${decimal}\[ \t\]*return ans;.* STEP .*" "step in solib call"
 
 # Verify that we can step out of the shlib call, and back out into
 # the caller.
 #
-gdb_test_multiple "next" "step out of solib call" {
-    -re "0x\[0-9a-f\]*\[ \t\]*9\[ \t\]*.*$gdb_prompt $" {
-	gdb_test "next" \
-	    "main .. at.*so-impl-ld.c:22.*" \
-	    "step out of solib call"
-    }
-    -re "main .. at.*so-impl-ld.c:22.*$gdb_prompt $" {
-	pass "step out of solib call"
-    }
-}
+gdb_step_until ".*main .. at.*return 0;.*" "step out of solib call"
 
 gdb_exit
 return 0
diff --git a/gdb/testsuite/gdb.base/solib1.c b/gdb/testsuite/gdb.base/solib1.c
index 16b72338f26..bf52beec5de 100644
--- a/gdb/testsuite/gdb.base/solib1.c
+++ b/gdb/testsuite/gdb.base/solib1.c
@@ -4,5 +4,6 @@ extern "C"
 int
 solib_main (int arg)
 {
-  return arg*arg;		/* HERE */
-}				/* STEP */
+  int ans = arg*arg;		/* HERE */
+  return ans;			/* STEP */
+}
-- 
2.31.1

Re: [PATCH v4 11/15] gdb/testsuite: Update gdb.base/so-impl-ld.exp

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
> epilogue information and that GDB would stop in the } line.  This would
> make clang tests fail like so:
>
>  step^M
>  solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
>  7|__  return arg*arg;|__|___/* HERE */^M
>  (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
>  next^M
>  main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
>  22|_  return 0;^M
>  (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
>  next^M
>  0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
>  (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call
>
> This patch changes it so solib_main has 2 lines where GDB can stop
> regardless of compiler weirdness, and updates the exp file to

s/weirdness/choices/ - I don't think there's necessarily anything
"weird" about Clang's choice, it's just different.

With that change, I think you can push this patch, and the patch that
provides gdb_step_until.

Thanks,
Andrew

> generically deal with unknown number of steps until leaving that
> function.
> ---
>  gdb/testsuite/gdb.base/so-impl-ld.exp | 13 ++-----------
>  gdb/testsuite/gdb.base/solib1.c       |  5 +++--
>  2 files changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/so-impl-ld.exp b/gdb/testsuite/gdb.base/so-impl-ld.exp
> index 372b18f3915..3c5d1070a5b 100644
> --- a/gdb/testsuite/gdb.base/so-impl-ld.exp
> +++ b/gdb/testsuite/gdb.base/so-impl-ld.exp
> @@ -56,21 +56,12 @@ gdb_test "step" "solib_main .arg=10000. at.*${libfile}.c:${decimal}.* HERE .*" \
>  
>  # Verify that we can step within the shlib call.
>  #
> -gdb_test "next" "${decimal}\[ \t\]*\}.* STEP .*" "step in solib call"
> +gdb_test "next" "${decimal}\[ \t\]*return ans;.* STEP .*" "step in solib call"
>  
>  # Verify that we can step out of the shlib call, and back out into
>  # the caller.
>  #
> -gdb_test_multiple "next" "step out of solib call" {
> -    -re "0x\[0-9a-f\]*\[ \t\]*9\[ \t\]*.*$gdb_prompt $" {
> -	gdb_test "next" \
> -	    "main .. at.*so-impl-ld.c:22.*" \
> -	    "step out of solib call"
> -    }
> -    -re "main .. at.*so-impl-ld.c:22.*$gdb_prompt $" {
> -	pass "step out of solib call"
> -    }
> -}
> +gdb_step_until ".*main .. at.*return 0;.*" "step out of solib call"
>  
>  gdb_exit
>  return 0
> diff --git a/gdb/testsuite/gdb.base/solib1.c b/gdb/testsuite/gdb.base/solib1.c
> index 16b72338f26..bf52beec5de 100644
> --- a/gdb/testsuite/gdb.base/solib1.c
> +++ b/gdb/testsuite/gdb.base/solib1.c
> @@ -4,5 +4,6 @@ extern "C"
>  int
>  solib_main (int arg)
>  {
> -  return arg*arg;		/* HERE */
> -}				/* STEP */
> +  int ans = arg*arg;		/* HERE */
> +  return ans;			/* STEP */
> +}
> -- 
> 2.31.1

Re: [PATCH v4 11/15] gdb/testsuite: Update gdb.base/so-impl-ld.exp

[Bruno Larsen]

Thanks, I pushed them both!

Cheers,
Bruno

On 12/09/2022 14:30, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> gdb.base/so-impl-ld.exp was setup assuming that the compiler would add
>> epilogue information and that GDB would stop in the } line.  This would
>> make clang tests fail like so:
>>
>>   step^M
>>   solib_main (arg=10000) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/solib1.c:7^M
>>   7|__  return arg*arg;|__|___/* HERE */^M
>>   (gdb) PASS: gdb.base/so-impl-ld.exp: step into solib call
>>   next^M
>>   main () at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/so-impl-ld.c:22^M
>>   22|_  return 0;^M
>>   (gdb) FAIL: gdb.base/so-impl-ld.exp: step in solib call
>>   next^M
>>   0x00007ffff7cef560 in __libc_start_call_main () from /lib64/libc.so.6^M
>>   (gdb) FAIL: gdb.base/so-impl-ld.exp: step out of solib call
>>
>> This patch changes it so solib_main has 2 lines where GDB can stop
>> regardless of compiler weirdness, and updates the exp file to
> s/weirdness/choices/ - I don't think there's necessarily anything
> "weird" about Clang's choice, it's just different.
>
> With that change, I think you can push this patch, and the patch that
> provides gdb_step_until.
>
> Thanks,
> Andrew
>
>> generically deal with unknown number of steps until leaving that
>> function.
>> ---
>>   gdb/testsuite/gdb.base/so-impl-ld.exp | 13 ++-----------
>>   gdb/testsuite/gdb.base/solib1.c       |  5 +++--
>>   2 files changed, 5 insertions(+), 13 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/so-impl-ld.exp b/gdb/testsuite/gdb.base/so-impl-ld.exp
>> index 372b18f3915..3c5d1070a5b 100644
>> --- a/gdb/testsuite/gdb.base/so-impl-ld.exp
>> +++ b/gdb/testsuite/gdb.base/so-impl-ld.exp
>> @@ -56,21 +56,12 @@ gdb_test "step" "solib_main .arg=10000. at.*${libfile}.c:${decimal}.* HERE .*" \
>>   
>>   # Verify that we can step within the shlib call.
>>   #
>> -gdb_test "next" "${decimal}\[ \t\]*\}.* STEP .*" "step in solib call"
>> +gdb_test "next" "${decimal}\[ \t\]*return ans;.* STEP .*" "step in solib call"
>>   
>>   # Verify that we can step out of the shlib call, and back out into
>>   # the caller.
>>   #
>> -gdb_test_multiple "next" "step out of solib call" {
>> -    -re "0x\[0-9a-f\]*\[ \t\]*9\[ \t\]*.*$gdb_prompt $" {
>> -	gdb_test "next" \
>> -	    "main .. at.*so-impl-ld.c:22.*" \
>> -	    "step out of solib call"
>> -    }
>> -    -re "main .. at.*so-impl-ld.c:22.*$gdb_prompt $" {
>> -	pass "step out of solib call"
>> -    }
>> -}
>> +gdb_step_until ".*main .. at.*return 0;.*" "step out of solib call"
>>   
>>   gdb_exit
>>   return 0
>> diff --git a/gdb/testsuite/gdb.base/solib1.c b/gdb/testsuite/gdb.base/solib1.c
>> index 16b72338f26..bf52beec5de 100644
>> --- a/gdb/testsuite/gdb.base/solib1.c
>> +++ b/gdb/testsuite/gdb.base/solib1.c
>> @@ -4,5 +4,6 @@ extern "C"
>>   int
>>   solib_main (int arg)
>>   {
>> -  return arg*arg;		/* HERE */
>> -}				/* STEP */
>> +  int ans = arg*arg;		/* HERE */
>> +  return ans;			/* STEP */
>> +}
>> -- 
>> 2.31.1

[PATCH v4 12/15] [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang

[Bruno Larsen]

When using clang as the compiler for the target, gdb.base/jit-elf.exp
was failing with the following output:

       (gdb) attach 3674146
       Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
       Reading symbols from /lib64/libm.so.6...
       Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
       (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
       Reading symbols from /lib64/libc.so.6...
       (No debugging symbols found in /lib64/libc.so.6)
       Reading symbols from /lib64/ld-linux-x86-64.so.2...
       [Thread debugging using libthread_db enabled]
       Using host libthread_db library "/lib64/libthread_db.so.1".
       0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
       118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
       (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach

While gcc's output is as follows:

       (gdb) attach 3592961
       Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
       Reading symbols from /lib64/libm.so.6...
       Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
       (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
       Reading symbols from /lib64/libc.so.6...
       (No debugging symbols found in /lib64/libc.so.6)
       Reading symbols from /lib64/ld-linux-x86-64.so.2...
       [Thread debugging using libthread_db enabled]
       Using host libthread_db library "/lib64/libthread_db.so.1".
       main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
       118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
       (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach

Clang-compiled code is clearly working, as gdb is attaching and running
to the established breakpoint. To fix the false positive, the regexp for
checking where gdb has stopped was relaxed a little, to allow for the
address at the start of the line, and to allow the relative path.
---
 gdb/testsuite/gdb.base/jit-elf.exp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.base/jit-elf.exp b/gdb/testsuite/gdb.base/jit-elf.exp
index 38d541f74b9..0f296dfd579 100644
--- a/gdb/testsuite/gdb.base/jit-elf.exp
+++ b/gdb/testsuite/gdb.base/jit-elf.exp
@@ -54,7 +54,7 @@ proc clean_reattach {} {
     clean_restart ${main_binfile}
 
     if { ![gdb_attach $testpid \
-	      -pattern "main.*at .*$::main_srcfile:.*"] } {
+	      -pattern ".*main.*at .*$::main_basename.c:.*"] } {
 	return 0
     }
 
-- 
2.31.1

Re: [PATCH v4 12/15] [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> When using clang as the compiler for the target, gdb.base/jit-elf.exp
> was failing with the following output:
>
>        (gdb) attach 3674146
>        Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3674146
>        Reading symbols from /lib64/libm.so.6...
>        Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
>        (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
>        Reading symbols from /lib64/libc.so.6...
>        (No debugging symbols found in /lib64/libc.so.6)
>        Reading symbols from /lib64/ld-linux-x86-64.so.2...
>        [Thread debugging using libthread_db enabled]
>        Using host libthread_db library "/lib64/libthread_db.so.1".
>        0x00000000004013ff in main (argc=3, argv=0x7fffffffd820) at ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
>        118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
>        (gdb) FAIL: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
>
> While gcc's output is as follows:
>
>        (gdb) attach 3592961
>        Attaching to program: /home/blarsen/Documents/gdb-build/gdb/testsuite/outputs/gdb.base/jit-elf/jit-elf-main, process 3592961
>        Reading symbols from /lib64/libm.so.6...
>        Reading symbols from .gnu_debugdata for /lib64/libm.so.6...
>        (No debugging symbols found in .gnu_debugdata for /lib64/libm.so.6)
>        Reading symbols from /lib64/libc.so.6...
>        (No debugging symbols found in /lib64/libc.so.6)
>        Reading symbols from /lib64/ld-linux-x86-64.so.2...
>        [Thread debugging using libthread_db enabled]
>        Using host libthread_db library "/lib64/libthread_db.so.1".
>        main (argc=3, argv=0x7fffffffd860) at /home/blarsen/Documents/gdb-build/gdb/testsuite/../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/jit-elf-main.c:118
>        118|  WAIT_FOR_GDB; i = 0;  /* gdb break here 1 */
>        (gdb) PASS: gdb.base/jit-elf.exp: attach: one_jit_test-2: break here 1: attach
>
> Clang-compiled code is clearly working, as gdb is attaching and running
> to the established breakpoint.

I think it would be helpful if you could point out exactly what _is_
causing the failure, see below for why...

>                                To fix the false positive, the regexp for
> checking where gdb has stopped was relaxed a little, to allow for the
> address at the start of the line, and to allow the relative path.
> ---
>  gdb/testsuite/gdb.base/jit-elf.exp | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gdb/testsuite/gdb.base/jit-elf.exp b/gdb/testsuite/gdb.base/jit-elf.exp
> index 38d541f74b9..0f296dfd579 100644
> --- a/gdb/testsuite/gdb.base/jit-elf.exp
> +++ b/gdb/testsuite/gdb.base/jit-elf.exp
> @@ -54,7 +54,7 @@ proc clean_reattach {} {
>      clean_restart ${main_binfile}
>  
>      if { ![gdb_attach $testpid \
> -	      -pattern "main.*at .*$::main_srcfile:.*"] } {
> +	      -pattern ".*main.*at .*$::main_basename.c:.*"] } {

... when I run this test using Clang (9.0.1) _without_ this patch, the
test passes.  I notice that when you ran the test the source file
reported at the breakpoint doesn't include the ${srcdir}.

I don't know why you're only seeing a relative path, but I guess, as far
as this test is concerned, just checking for the final filename is fine.

I don't think the change to add the leading '.*' is needed though.  The
pattern is never anchored to the start of a line, so expect will happily
skip any leading content when looking for a match, the extra '.*' is
just unnecessary noise.

Thanks,
Andrew

>  	return 0
>      }
>  
> -- 
> 2.31.1

[PATCH v4 13/15] gdb/testsuite: fix gdb.base/info-types-c++ with clang

[Bruno Larsen]

When g++ compiles nameles structs defined in a typedef, it adds a
DW_AT_linkage_name with the name defined in the typedef.  So when
running gdb.base/info-types-c++.exp by default, we get the following
output

    All defined types:

    File ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
    98:     CL;
    42:     anon_struct_t;
    65:     anon_union_t;
    21:     baz_t;
    33:     enum_t;
    56:     union_t;
    52:     typedef enum {...} anon_enum_t;
    45:     typedef anon_struct_t anon_struct_t;
    68:     typedef anon_union_t anon_union_t;

Clang[++] does not add DW_AT_linkage_name, and so it's output looks like
this:

    All defined types:

    File ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
    98:     CL;
    21:     baz_t;
    33:     enum_t;
    56:     union_t;
    52:     typedef enum {...} anon_enum_t;
    45:     typedef struct {...} anon_struct_t;
    68:     typedef union {...} anon_union_t;

Which is still correct output for GDB, but shows up as a failure when
running the test. This commit changes the test to allow for this output
when the compiler is clang.
---
 gdb/testsuite/gdb.base/info-types.exp.tcl | 109 +++++++++++++++-------
 1 file changed, 73 insertions(+), 36 deletions(-)

diff --git a/gdb/testsuite/gdb.base/info-types.exp.tcl b/gdb/testsuite/gdb.base/info-types.exp.tcl
index 2dd9b9e5489..b6a03276f69 100644
--- a/gdb/testsuite/gdb.base/info-types.exp.tcl
+++ b/gdb/testsuite/gdb.base/info-types.exp.tcl
@@ -41,42 +41,79 @@ proc run_test { lang } {
     set file_re "File .*[string_to_regexp $srcfile]:"
 
     if { $lang == "c++" } {
-	set output_lines \
-	    [list \
-		 "^All defined types:" \
-		 ".*" \
-		 $file_re \
-		 "98:\[\t \]+CL;" \
-		 "42:\[\t \]+anon_struct_t;" \
-		 "65:\[\t \]+anon_union_t;" \
-		 "21:\[\t \]+baz_t;" \
-		 "33:\[\t \]+enum_t;" \
-		 "56:\[\t \]+union_t;" \
-		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
-		 "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
-		 "68:\[\t \]+typedef anon_union_t anon_union_t;" \
-		 "28:\[\t \]+typedef baz_t baz;" \
-		 "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
-		 "27:\[\t \]+typedef baz_t baz_t;" \
-		 "\[\t \]+double" \
-		 "\[\t \]+float" \
-		 "\[\t \]+int" \
-		 "103:\[\t \]+typedef CL my_cl;" \
-		 "38:\[\t \]+typedef enum_t my_enum_t;" \
-		 "17:\[\t \]+typedef float my_float_t;" \
-		 "16:\[\t \]+typedef int my_int_t;" \
-		 "104:\[\t \]+typedef CL \\* my_ptr;" \
-		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
-		 "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
-		 "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
-		 "30:\[\t \]+typedef baz_t nested_baz;" \
-		 "29:\[\t \]+typedef baz_t nested_baz_t;" \
-		 "39:\[\t \]+typedef enum_t nested_enum_t;" \
-		 "19:\[\t \]+typedef float nested_float_t;" \
-		 "18:\[\t \]+typedef int nested_int_t;" \
-		 "62:\[\t \]+typedef union_t nested_union_t;(" \
-		 "\[\t \]+unsigned int)?" \
-		 "($|\r\n.*)"]
+	if { [test_compiler_info "clang-*"] } {
+	    set output_lines \
+		[list \
+		     "^All defined types:" \
+		     ".*" \
+		     $file_re \
+		     "98:\[\t \]+CL;" \
+		     "21:\[\t \]+baz_t;" \
+		     "33:\[\t \]+enum_t;" \
+		     "56:\[\t \]+union_t;" \
+		     "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
+		     "45:\[\t \]+typedef struct {\\.\\.\\.} anon_struct_t;" \
+		     "68:\[\t \]+typedef union {\\.\\.\\.} anon_union_t;" \
+		     "28:\[\t \]+typedef baz_t baz;" \
+		     "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
+		     "27:\[\t \]+typedef baz_t baz_t;" \
+		     "\[\t \]+double" \
+		     "\[\t \]+float" \
+		     "\[\t \]+int" \
+		     "103:\[\t \]+typedef CL my_cl;" \
+		     "38:\[\t \]+typedef enum_t my_enum_t;" \
+		     "17:\[\t \]+typedef float my_float_t;" \
+		     "16:\[\t \]+typedef int my_int_t;" \
+		     "104:\[\t \]+typedef CL \\* my_ptr;" \
+		     "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
+		     "47:\[\t \]+typedef struct {\\.\\.\\.} nested_anon_struct_t;" \
+		     "70:\[\t \]+typedef union {\\.\\.\\.} nested_anon_union_t;" \
+		     "30:\[\t \]+typedef baz_t nested_baz;" \
+		     "29:\[\t \]+typedef baz_t nested_baz_t;" \
+		     "39:\[\t \]+typedef enum_t nested_enum_t;" \
+		     "19:\[\t \]+typedef float nested_float_t;" \
+		     "18:\[\t \]+typedef int nested_int_t;" \
+		     "62:\[\t \]+typedef union_t nested_union_t;(" \
+		     "\[\t \]+unsigned int)?" \
+		     "($|\r\n.*)"]
+	 } else {
+	    set output_lines \
+		[list \
+		     "^All defined types:" \
+		     ".*" \
+		     $file_re \
+		     "98:\[\t \]+CL;" \
+		     "42:\[\t \]+anon_struct_t;" \
+		     "65:\[\t \]+anon_union_t;" \
+		     "21:\[\t \]+baz_t;" \
+		     "33:\[\t \]+enum_t;" \
+		     "56:\[\t \]+union_t;" \
+		     "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
+		     "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
+		     "68:\[\t \]+typedef anon_union_t anon_union_t;" \
+		     "28:\[\t \]+typedef baz_t baz;" \
+		     "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
+		     "27:\[\t \]+typedef baz_t baz_t;" \
+		     "\[\t \]+double" \
+		     "\[\t \]+float" \
+		     "\[\t \]+int" \
+		     "103:\[\t \]+typedef CL my_cl;" \
+		     "38:\[\t \]+typedef enum_t my_enum_t;" \
+		     "17:\[\t \]+typedef float my_float_t;" \
+		     "16:\[\t \]+typedef int my_int_t;" \
+		     "104:\[\t \]+typedef CL \\* my_ptr;" \
+		     "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
+		     "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
+		     "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
+		     "30:\[\t \]+typedef baz_t nested_baz;" \
+		     "29:\[\t \]+typedef baz_t nested_baz_t;" \
+		     "39:\[\t \]+typedef enum_t nested_enum_t;" \
+		     "19:\[\t \]+typedef float nested_float_t;" \
+		     "18:\[\t \]+typedef int nested_int_t;" \
+		     "62:\[\t \]+typedef union_t nested_union_t;(" \
+		     "\[\t \]+unsigned int)?" \
+		     "($|\r\n.*)"]
+	 }
     } else {
 	set output_lines \
 	    [list \
-- 
2.31.1

Re: [PATCH v4 13/15] gdb/testsuite: fix gdb.base/info-types-c++ with clang

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> When g++ compiles nameles structs defined in a typedef, it adds a
> DW_AT_linkage_name with the name defined in the typedef.  So when
> running gdb.base/info-types-c++.exp by default, we get the following
> output
>
>     All defined types:
>
>     File ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
>     98:     CL;
>     42:     anon_struct_t;
>     65:     anon_union_t;
>     21:     baz_t;
>     33:     enum_t;
>     56:     union_t;
>     52:     typedef enum {...} anon_enum_t;
>     45:     typedef anon_struct_t anon_struct_t;
>     68:     typedef anon_union_t anon_union_t;
>
> Clang[++] does not add DW_AT_linkage_name, and so it's output looks like
> this:
>
>     All defined types:
>
>     File ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
>     98:     CL;
>     21:     baz_t;
>     33:     enum_t;
>     56:     union_t;
>     52:     typedef enum {...} anon_enum_t;
>     45:     typedef struct {...} anon_struct_t;
>     68:     typedef union {...} anon_union_t;
>
> Which is still correct output for GDB, but shows up as a failure when
> running the test. This commit changes the test to allow for this output
> when the compiler is clang.
> ---
>  gdb/testsuite/gdb.base/info-types.exp.tcl | 109 +++++++++++++++-------
>  1 file changed, 73 insertions(+), 36 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/info-types.exp.tcl b/gdb/testsuite/gdb.base/info-types.exp.tcl
> index 2dd9b9e5489..b6a03276f69 100644
> --- a/gdb/testsuite/gdb.base/info-types.exp.tcl
> +++ b/gdb/testsuite/gdb.base/info-types.exp.tcl
> @@ -41,42 +41,79 @@ proc run_test { lang } {
>      set file_re "File .*[string_to_regexp $srcfile]:"
>  
>      if { $lang == "c++" } {
> -	set output_lines \
> -	    [list \
> -		 "^All defined types:" \
> -		 ".*" \
> -		 $file_re \
> -		 "98:\[\t \]+CL;" \
> -		 "42:\[\t \]+anon_struct_t;" \
> -		 "65:\[\t \]+anon_union_t;" \
> -		 "21:\[\t \]+baz_t;" \
> -		 "33:\[\t \]+enum_t;" \
> -		 "56:\[\t \]+union_t;" \
> -		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
> -		 "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
> -		 "68:\[\t \]+typedef anon_union_t anon_union_t;" \
> -		 "28:\[\t \]+typedef baz_t baz;" \
> -		 "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
> -		 "27:\[\t \]+typedef baz_t baz_t;" \
> -		 "\[\t \]+double" \
> -		 "\[\t \]+float" \
> -		 "\[\t \]+int" \
> -		 "103:\[\t \]+typedef CL my_cl;" \
> -		 "38:\[\t \]+typedef enum_t my_enum_t;" \
> -		 "17:\[\t \]+typedef float my_float_t;" \
> -		 "16:\[\t \]+typedef int my_int_t;" \
> -		 "104:\[\t \]+typedef CL \\* my_ptr;" \
> -		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
> -		 "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
> -		 "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
> -		 "30:\[\t \]+typedef baz_t nested_baz;" \
> -		 "29:\[\t \]+typedef baz_t nested_baz_t;" \
> -		 "39:\[\t \]+typedef enum_t nested_enum_t;" \
> -		 "19:\[\t \]+typedef float nested_float_t;" \
> -		 "18:\[\t \]+typedef int nested_int_t;" \
> -		 "62:\[\t \]+typedef union_t nested_union_t;(" \
> -		 "\[\t \]+unsigned int)?" \
> -		 "($|\r\n.*)"]
> +	if { [test_compiler_info "clang-*"] } {
> +	    set output_lines \
> +		[list \
> +		     "^All defined types:" \
> +		     ".*" \
> +		     $file_re \
> +		     "98:\[\t \]+CL;" \
> +		     "21:\[\t \]+baz_t;" \
> +		     "33:\[\t \]+enum_t;" \
> +		     "56:\[\t \]+union_t;" \
> +		     "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
> +		     "45:\[\t \]+typedef struct {\\.\\.\\.} anon_struct_t;" \
> +		     "68:\[\t \]+typedef union {\\.\\.\\.} anon_union_t;" \
> +		     "28:\[\t \]+typedef baz_t baz;" \
> +		     "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
> +		     "27:\[\t \]+typedef baz_t baz_t;" \
> +		     "\[\t \]+double" \
> +		     "\[\t \]+float" \
> +		     "\[\t \]+int" \
> +		     "103:\[\t \]+typedef CL my_cl;" \
> +		     "38:\[\t \]+typedef enum_t my_enum_t;" \
> +		     "17:\[\t \]+typedef float my_float_t;" \
> +		     "16:\[\t \]+typedef int my_int_t;" \
> +		     "104:\[\t \]+typedef CL \\* my_ptr;" \
> +		     "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
> +		     "47:\[\t \]+typedef struct {\\.\\.\\.} nested_anon_struct_t;" \
> +		     "70:\[\t \]+typedef union {\\.\\.\\.} nested_anon_union_t;" \
> +		     "30:\[\t \]+typedef baz_t nested_baz;" \
> +		     "29:\[\t \]+typedef baz_t nested_baz_t;" \
> +		     "39:\[\t \]+typedef enum_t nested_enum_t;" \
> +		     "19:\[\t \]+typedef float nested_float_t;" \
> +		     "18:\[\t \]+typedef int nested_int_t;" \
> +		     "62:\[\t \]+typedef union_t nested_union_t;(" \
> +		     "\[\t \]+unsigned int)?" \
> +		     "($|\r\n.*)"]
> +	 } else {
> +	    set output_lines \
> +		[list \
> +		     "^All defined types:" \
> +		     ".*" \
> +		     $file_re \
> +		     "98:\[\t \]+CL;" \
> +		     "42:\[\t \]+anon_struct_t;" \
> +		     "65:\[\t \]+anon_union_t;" \
> +		     "21:\[\t \]+baz_t;" \
> +		     "33:\[\t \]+enum_t;" \
> +		     "56:\[\t \]+union_t;" \
> +		     "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
> +		     "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
> +		     "68:\[\t \]+typedef anon_union_t anon_union_t;" \
> +		     "28:\[\t \]+typedef baz_t baz;" \
> +		     "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
> +		     "27:\[\t \]+typedef baz_t baz_t;" \
> +		     "\[\t \]+double" \
> +		     "\[\t \]+float" \
> +		     "\[\t \]+int" \
> +		     "103:\[\t \]+typedef CL my_cl;" \
> +		     "38:\[\t \]+typedef enum_t my_enum_t;" \
> +		     "17:\[\t \]+typedef float my_float_t;" \
> +		     "16:\[\t \]+typedef int my_int_t;" \
> +		     "104:\[\t \]+typedef CL \\* my_ptr;" \
> +		     "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
> +		     "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
> +		     "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
> +		     "30:\[\t \]+typedef baz_t nested_baz;" \
> +		     "29:\[\t \]+typedef baz_t nested_baz_t;" \
> +		     "39:\[\t \]+typedef enum_t nested_enum_t;" \
> +		     "19:\[\t \]+typedef float nested_float_t;" \
> +		     "18:\[\t \]+typedef int nested_int_t;" \
> +		     "62:\[\t \]+typedef union_t nested_union_t;(" \
> +		     "\[\t \]+unsigned int)?" \
> +		     "($|\r\n.*)"]
> +	 }
>      } else {
>  	set output_lines \
>  	    [list \
> -- 
> 2.31.1


Rather than duplicating the whole pattern block like this, I wondered if
we could rewrite the test to, I hope, make things a little clearer.

Below is my attempt to do this.  This patch applies instead of your
patch above, and I believe results in the test passing with GCC and
Clang.

I wonder what you think of this as an alternative approach?

Thanks,
Andrew

---

commit 313bcb258d6a1e00dd8e93fbbbaa2df2d4a49e61
Author: Andrew Burgess <aburgess@redhat.com>
Date:   Mon Sep 12 15:24:14 2022 +0100

    gdb: rewrite gdb.base/info-types.exp.tcl
    
    This patch was inspired by this proposed change:
    
      https://sourceware.org/pipermail/gdb-patches/2022-July/190926.html
    
    the goal of that change was to make the info-types tests pass when
    using Clang as a compiler.  The difference between g++ and Clang, is
    that g++ will give a (made up) name to an anonymous struct or union
    that is used in a typedef, Clang doesn't.  The solution proposed in
    the patch above is to create a third test pattern to be used for
    C++/Clang, at this point the test script seemed to be getting a little
    bloated.
    
    In this commit I rewrite the test.  Instead of running the 'info
    types' command and expecting a specific set of lines in a particular
    order, we now read all the lines from the command output, and place
    the lines into a dictionary.  We can then query the dictionary to
    check the all the expected lines are present.
    
    Checking for each output line independently has a couple of
    advantages:
    
     1. We no longer care about the output order.  I don't think the
     ordering is particularly important for this test, so long as all the
     expected lines are present,
    
     2. For lines that are present in both C and C++ we can now share the
     code to check these patterns, I think this makes it clearer what is
     going on, and
    
     3. It is easy to place a few lines within an `if` block, and so, only
     check for those lines when using a specific compiler.
    
    I've check gdb.base/info-types-c.exp and gdb.base/info-types-c++.exp
    using both GCC and Clang.

diff --git a/gdb/testsuite/gdb.base/info-types.exp.tcl b/gdb/testsuite/gdb.base/info-types.exp.tcl
index 2dd9b9e5489..8aa006d0179 100644
--- a/gdb/testsuite/gdb.base/info-types.exp.tcl
+++ b/gdb/testsuite/gdb.base/info-types.exp.tcl
@@ -16,6 +16,113 @@
 # Check that 'info types' produces the expected output for an inferior
 # containing a number of different types.
 
+
+# Run the 'info types' command, and place the results into RESULT_VAR,
+# which should be the name of a variable in the callers scope.
+#
+# RESULT_VAR will be cleared, and set to an associative array, the
+# keys of this associative array will be the line numbers, and the
+# value for each line number will be a list of the types GDB
+# understands to be declared on that line.
+#
+# Some types don't have a line number for their declartion
+# (e.g. builtin types), these are placed into a list for the special
+# line number 'NONE'.
+#
+# Finally, only types from the reported in SRCFILE are collected, any
+# types reported from other files (e.g. libraries linked into the
+# test) should be ignored.
+proc collect_output { result_var } {
+    upvar $result_var result_obj
+
+    array set result_obj {}
+
+    set collect_lines false
+    gdb_test_multiple "info types" "" {
+	-re "^info types\r\n" {
+	    exp_continue
+	}
+
+	-re "^\r\n" {
+	    exp_continue
+	}
+
+	-re "^All defined types:\r\n" {
+	    exp_continue
+	}
+
+	-re "^File (\[^\r\n\]+)\r\n" {
+	    set filename $expect_out(1,string)
+	    set collect_lines [regexp [string_to_regexp $::srcfile] $filename]
+	    exp_continue
+	}
+
+	-re "^($::decimal):\\s+(\[^\r\n\]+);\r\n" {
+	    set lineno $expect_out(1,string)
+	    set text $expect_out(2,string)
+	    if { $collect_lines } {
+		if { ! [info exists result_obj($lineno)] } {
+		    set result_obj($lineno) [list]
+		}
+		lappend result_obj($lineno) $text
+	    }
+	    exp_continue
+	}
+
+	-re "^\\s+(\[^\r\n;\]+)\r\n" {
+	    set text $expect_out(1,string)
+	    if { $collect_lines } {
+		if { ![info exists result_obj(NONE)] } {
+		    set result_obj(NONE) [list]
+		}
+		lappend result_obj(NONE) $text
+	    }
+	    exp_continue
+	}
+
+	-re "^$::gdb_prompt $" {
+	}
+    }
+}
+
+# RESULT_VAR is the name of a variable in the parent scope that
+# contains an associative array of results as returned from the
+# collect_output proc.
+#
+# LINE is a line number, or the empty string, and TEXT is the
+# declaration of a type that GDB should have seen on that line.
+#
+# This proc checks in RESULT_VAR for a matching entry to LINE and
+# TEXT, and, if a matching entry is found, calls pass, otherwise, fail
+# is called.  The testname used for the pass/fail call is based on
+# LINE and TEXT.
+#
+# If LINE is the empty string then this proc looks for a result
+# associated with the special line number 'NONE', see collect_output
+# for more details.
+proc require_line { result_var line text } {
+    upvar $result_var result_obj
+
+    set testname "check for $text"
+    if { $line != "" } {
+	set testname "$testname on line $line"
+    } else {
+	set line "NONE"
+    }
+
+    if { ![info exists result_obj($line)] } {
+	fail $testname
+	return
+    }
+
+    if { [lsearch -exact $result_obj($line) $text] < 0 } {
+	fail $testname
+	return
+    }
+
+    pass $testname
+}
+
 # Run 'info types' test, compiling the test file for language LANG,
 # which should be either 'c' or 'c++'.
 proc run_test { lang } {
@@ -38,79 +145,71 @@ proc run_test { lang } {
 	return 0
     }
 
-    set file_re "File .*[string_to_regexp $srcfile]:"
+    # Run 'info types' and place the results in RESULT_OBJ.
+    collect_output result_obj
+
+    # Some results are common to C and C++.  These are the builtin
+    # types which are not declared on any specific line.
+    require_line result_obj "" "double"
+    require_line result_obj "" "float"
+    require_line result_obj "" "int"
+
+    # These typedefs are common to C and C++, but GDB should see a
+    # specific line number for these type declarations.
+    require_line result_obj "16" "typedef int my_int_t"
+    require_line result_obj "17" "typedef float my_float_t"
+    require_line result_obj "18" "typedef int nested_int_t"
+    require_line result_obj "19" "typedef float nested_float_t"
 
     if { $lang == "c++" } {
-	set output_lines \
-	    [list \
-		 "^All defined types:" \
-		 ".*" \
-		 $file_re \
-		 "98:\[\t \]+CL;" \
-		 "42:\[\t \]+anon_struct_t;" \
-		 "65:\[\t \]+anon_union_t;" \
-		 "21:\[\t \]+baz_t;" \
-		 "33:\[\t \]+enum_t;" \
-		 "56:\[\t \]+union_t;" \
-		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
-		 "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
-		 "68:\[\t \]+typedef anon_union_t anon_union_t;" \
-		 "28:\[\t \]+typedef baz_t baz;" \
-		 "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
-		 "27:\[\t \]+typedef baz_t baz_t;" \
-		 "\[\t \]+double" \
-		 "\[\t \]+float" \
-		 "\[\t \]+int" \
-		 "103:\[\t \]+typedef CL my_cl;" \
-		 "38:\[\t \]+typedef enum_t my_enum_t;" \
-		 "17:\[\t \]+typedef float my_float_t;" \
-		 "16:\[\t \]+typedef int my_int_t;" \
-		 "104:\[\t \]+typedef CL \\* my_ptr;" \
-		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
-		 "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
-		 "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
-		 "30:\[\t \]+typedef baz_t nested_baz;" \
-		 "29:\[\t \]+typedef baz_t nested_baz_t;" \
-		 "39:\[\t \]+typedef enum_t nested_enum_t;" \
-		 "19:\[\t \]+typedef float nested_float_t;" \
-		 "18:\[\t \]+typedef int nested_int_t;" \
-		 "62:\[\t \]+typedef union_t nested_union_t;(" \
-		 "\[\t \]+unsigned int)?" \
-		 "($|\r\n.*)"]
+	# These results are specific to 'C++'.
+	require_line result_obj "21" "baz_t"
+	require_line result_obj "27" "typedef baz_t baz_t"
+	require_line result_obj "28" "typedef baz_t baz"
+	require_line result_obj "29" "typedef baz_t nested_baz_t"
+	require_line result_obj "30" "typedef baz_t nested_baz"
+	require_line result_obj "31" "typedef baz_t * baz_ptr"
+	require_line result_obj "33" "enum_t"
+	require_line result_obj "38" "typedef enum_t my_enum_t"
+	require_line result_obj "39" "typedef enum_t nested_enum_t"
+	require_line result_obj "52" "typedef enum {...} anon_enum_t"
+	require_line result_obj "54" "typedef enum {...} nested_anon_enum_t"
+	require_line result_obj "56" "union_t"
+	require_line result_obj "62" "typedef union_t nested_union_t"
+	require_line result_obj "98" "CL"
+	require_line result_obj "103" "typedef CL my_cl"
+	require_line result_obj "104" "typedef CL * my_ptr"
+
+	if { [test_compiler_info "gcc-*"] } {
+	    # GCC give a name to anonymous structs and unions.  Not
+	    # all compilers do this, e.g. Clang does not.
+	    require_line result_obj "42" "anon_struct_t"
+	    require_line result_obj "45" "typedef anon_struct_t anon_struct_t"
+	    require_line result_obj "47" "typedef anon_struct_t nested_anon_struct_t"
+	    require_line result_obj "65" "anon_union_t"
+	    require_line result_obj "68" "typedef anon_union_t anon_union_t"
+	    require_line result_obj "70" "typedef anon_union_t nested_anon_union_t"
+	}
+
     } else {
-	set output_lines \
-	    [list \
-		 "^All defined types:" \
-		 ".*" \
-		 $file_re \
-		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
-		 "45:\[\t \]+typedef struct {\\.\\.\\.} anon_struct_t;" \
-		 "68:\[\t \]+typedef union {\\.\\.\\.} anon_union_t;" \
-		 "28:\[\t \]+typedef struct baz_t baz;" \
-		 "31:\[\t \]+typedef struct baz_t \\* baz_ptr;" \
-		 "21:\[\t \]+struct baz_t;" \
-		 "\[\t \]+double" \
-		 "33:\[\t \]+enum enum_t;" \
-		 "\[\t \]+float" \
-		 "\[\t \]+int" \
-		 "38:\[\t \]+typedef enum enum_t my_enum_t;" \
-		 "17:\[\t \]+typedef float my_float_t;" \
-		 "16:\[\t \]+typedef int my_int_t;" \
-		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
-		 "47:\[\t \]+typedef struct {\\.\\.\\.} nested_anon_struct_t;" \
-		 "70:\[\t \]+typedef union {\\.\\.\\.} nested_anon_union_t;" \
-		 "30:\[\t \]+typedef struct baz_t nested_baz;" \
-		 "29:\[\t \]+typedef struct baz_t nested_baz_t;" \
-		 "39:\[\t \]+typedef enum enum_t nested_enum_t;" \
-		 "19:\[\t \]+typedef float nested_float_t;" \
-		 "18:\[\t \]+typedef int nested_int_t;" \
-		 "62:\[\t \]+typedef union union_t nested_union_t;" \
-		 "56:\[\t \]+union union_t;(" \
-		 "\[\t \]+unsigned int)?" \
-		 "($|\r\n.*)"]
+	# These results are specific to 'C'.
+	require_line result_obj "21" "struct baz_t"
+	require_line result_obj "28" "typedef struct baz_t baz"
+	require_line result_obj "29" "typedef struct baz_t nested_baz_t"
+	require_line result_obj "30" "typedef struct baz_t nested_baz"
+	require_line result_obj "31" "typedef struct baz_t * baz_ptr"
+	require_line result_obj "33" "enum enum_t"
+	require_line result_obj "38" "typedef enum enum_t my_enum_t"
+	require_line result_obj "39" "typedef enum enum_t nested_enum_t"
+	require_line result_obj "45" "typedef struct {...} anon_struct_t"
+	require_line result_obj "47" "typedef struct {...} nested_anon_struct_t"
+	require_line result_obj "52" "typedef enum {...} anon_enum_t"
+	require_line result_obj "54" "typedef enum {...} nested_anon_enum_t"
+	require_line result_obj "56" "union union_t"
+	require_line result_obj "62" "typedef union union_t nested_union_t"
+	require_line result_obj "68" "typedef union {...} anon_union_t"
+	require_line result_obj "70" "typedef union {...} nested_anon_union_t"
     }
-
-    gdb_test_lines "info types" "" [multi_line {*}$output_lines]
 }
 
 run_test $lang

Re: [PATCH v4 13/15] gdb/testsuite: fix gdb.base/info-types-c++ with clang

[Bruno Larsen]

On 12/09/2022 16:35, Andrew Burgess wrote:
> Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
>
>> When g++ compiles nameles structs defined in a typedef, it adds a
>> DW_AT_linkage_name with the name defined in the typedef.  So when
>> running gdb.base/info-types-c++.exp by default, we get the following
>> output
>>
>>      All defined types:
>>
>>      File ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
>>      98:     CL;
>>      42:     anon_struct_t;
>>      65:     anon_union_t;
>>      21:     baz_t;
>>      33:     enum_t;
>>      56:     union_t;
>>      52:     typedef enum {...} anon_enum_t;
>>      45:     typedef anon_struct_t anon_struct_t;
>>      68:     typedef anon_union_t anon_union_t;
>>
>> Clang[++] does not add DW_AT_linkage_name, and so it's output looks like
>> this:
>>
>>      All defined types:
>>
>>      File ../../../common/git-repos/binutils-gdb/gdb/testsuite/gdb.base/info-types.c:
>>      98:     CL;
>>      21:     baz_t;
>>      33:     enum_t;
>>      56:     union_t;
>>      52:     typedef enum {...} anon_enum_t;
>>      45:     typedef struct {...} anon_struct_t;
>>      68:     typedef union {...} anon_union_t;
>>
>> Which is still correct output for GDB, but shows up as a failure when
>> running the test. This commit changes the test to allow for this output
>> when the compiler is clang.
>> ---
>>   gdb/testsuite/gdb.base/info-types.exp.tcl | 109 +++++++++++++++-------
>>   1 file changed, 73 insertions(+), 36 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.base/info-types.exp.tcl b/gdb/testsuite/gdb.base/info-types.exp.tcl
>> index 2dd9b9e5489..b6a03276f69 100644
>> --- a/gdb/testsuite/gdb.base/info-types.exp.tcl
>> +++ b/gdb/testsuite/gdb.base/info-types.exp.tcl
>> @@ -41,42 +41,79 @@ proc run_test { lang } {
>>       set file_re "File .*[string_to_regexp $srcfile]:"
>>   
>>       if { $lang == "c++" } {
>> -	set output_lines \
>> -	    [list \
>> -		 "^All defined types:" \
>> -		 ".*" \
>> -		 $file_re \
>> -		 "98:\[\t \]+CL;" \
>> -		 "42:\[\t \]+anon_struct_t;" \
>> -		 "65:\[\t \]+anon_union_t;" \
>> -		 "21:\[\t \]+baz_t;" \
>> -		 "33:\[\t \]+enum_t;" \
>> -		 "56:\[\t \]+union_t;" \
>> -		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
>> -		 "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
>> -		 "68:\[\t \]+typedef anon_union_t anon_union_t;" \
>> -		 "28:\[\t \]+typedef baz_t baz;" \
>> -		 "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
>> -		 "27:\[\t \]+typedef baz_t baz_t;" \
>> -		 "\[\t \]+double" \
>> -		 "\[\t \]+float" \
>> -		 "\[\t \]+int" \
>> -		 "103:\[\t \]+typedef CL my_cl;" \
>> -		 "38:\[\t \]+typedef enum_t my_enum_t;" \
>> -		 "17:\[\t \]+typedef float my_float_t;" \
>> -		 "16:\[\t \]+typedef int my_int_t;" \
>> -		 "104:\[\t \]+typedef CL \\* my_ptr;" \
>> -		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
>> -		 "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
>> -		 "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
>> -		 "30:\[\t \]+typedef baz_t nested_baz;" \
>> -		 "29:\[\t \]+typedef baz_t nested_baz_t;" \
>> -		 "39:\[\t \]+typedef enum_t nested_enum_t;" \
>> -		 "19:\[\t \]+typedef float nested_float_t;" \
>> -		 "18:\[\t \]+typedef int nested_int_t;" \
>> -		 "62:\[\t \]+typedef union_t nested_union_t;(" \
>> -		 "\[\t \]+unsigned int)?" \
>> -		 "($|\r\n.*)"]
>> +	if { [test_compiler_info "clang-*"] } {
>> +	    set output_lines \
>> +		[list \
>> +		     "^All defined types:" \
>> +		     ".*" \
>> +		     $file_re \
>> +		     "98:\[\t \]+CL;" \
>> +		     "21:\[\t \]+baz_t;" \
>> +		     "33:\[\t \]+enum_t;" \
>> +		     "56:\[\t \]+union_t;" \
>> +		     "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
>> +		     "45:\[\t \]+typedef struct {\\.\\.\\.} anon_struct_t;" \
>> +		     "68:\[\t \]+typedef union {\\.\\.\\.} anon_union_t;" \
>> +		     "28:\[\t \]+typedef baz_t baz;" \
>> +		     "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
>> +		     "27:\[\t \]+typedef baz_t baz_t;" \
>> +		     "\[\t \]+double" \
>> +		     "\[\t \]+float" \
>> +		     "\[\t \]+int" \
>> +		     "103:\[\t \]+typedef CL my_cl;" \
>> +		     "38:\[\t \]+typedef enum_t my_enum_t;" \
>> +		     "17:\[\t \]+typedef float my_float_t;" \
>> +		     "16:\[\t \]+typedef int my_int_t;" \
>> +		     "104:\[\t \]+typedef CL \\* my_ptr;" \
>> +		     "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
>> +		     "47:\[\t \]+typedef struct {\\.\\.\\.} nested_anon_struct_t;" \
>> +		     "70:\[\t \]+typedef union {\\.\\.\\.} nested_anon_union_t;" \
>> +		     "30:\[\t \]+typedef baz_t nested_baz;" \
>> +		     "29:\[\t \]+typedef baz_t nested_baz_t;" \
>> +		     "39:\[\t \]+typedef enum_t nested_enum_t;" \
>> +		     "19:\[\t \]+typedef float nested_float_t;" \
>> +		     "18:\[\t \]+typedef int nested_int_t;" \
>> +		     "62:\[\t \]+typedef union_t nested_union_t;(" \
>> +		     "\[\t \]+unsigned int)?" \
>> +		     "($|\r\n.*)"]
>> +	 } else {
>> +	    set output_lines \
>> +		[list \
>> +		     "^All defined types:" \
>> +		     ".*" \
>> +		     $file_re \
>> +		     "98:\[\t \]+CL;" \
>> +		     "42:\[\t \]+anon_struct_t;" \
>> +		     "65:\[\t \]+anon_union_t;" \
>> +		     "21:\[\t \]+baz_t;" \
>> +		     "33:\[\t \]+enum_t;" \
>> +		     "56:\[\t \]+union_t;" \
>> +		     "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
>> +		     "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
>> +		     "68:\[\t \]+typedef anon_union_t anon_union_t;" \
>> +		     "28:\[\t \]+typedef baz_t baz;" \
>> +		     "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
>> +		     "27:\[\t \]+typedef baz_t baz_t;" \
>> +		     "\[\t \]+double" \
>> +		     "\[\t \]+float" \
>> +		     "\[\t \]+int" \
>> +		     "103:\[\t \]+typedef CL my_cl;" \
>> +		     "38:\[\t \]+typedef enum_t my_enum_t;" \
>> +		     "17:\[\t \]+typedef float my_float_t;" \
>> +		     "16:\[\t \]+typedef int my_int_t;" \
>> +		     "104:\[\t \]+typedef CL \\* my_ptr;" \
>> +		     "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
>> +		     "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
>> +		     "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
>> +		     "30:\[\t \]+typedef baz_t nested_baz;" \
>> +		     "29:\[\t \]+typedef baz_t nested_baz_t;" \
>> +		     "39:\[\t \]+typedef enum_t nested_enum_t;" \
>> +		     "19:\[\t \]+typedef float nested_float_t;" \
>> +		     "18:\[\t \]+typedef int nested_int_t;" \
>> +		     "62:\[\t \]+typedef union_t nested_union_t;(" \
>> +		     "\[\t \]+unsigned int)?" \
>> +		     "($|\r\n.*)"]
>> +	 }
>>       } else {
>>   	set output_lines \
>>   	    [list \
>> -- 
>> 2.31.1
>
> Rather than duplicating the whole pattern block like this, I wondered if
> we could rewrite the test to, I hope, make things a little clearer.
>
> Below is my attempt to do this.  This patch applies instead of your
> patch above, and I believe results in the test passing with GCC and
> Clang.
>
> I wonder what you think of this as an alternative approach?

I think this approach is definitely better. It is much more readable in 
the end, and re-uses as much code as possible, like you said.

I'll remove my patch for this test from my series, and I encourage you 
to either approve your own patch or post it as a standalone, if you want 
more eyes on it.

Cheers,
Bruno


>
> Thanks,
> Andrew
>
> ---
>
> commit 313bcb258d6a1e00dd8e93fbbbaa2df2d4a49e61
> Author: Andrew Burgess <aburgess@redhat.com>
> Date:   Mon Sep 12 15:24:14 2022 +0100
>
>      gdb: rewrite gdb.base/info-types.exp.tcl
>      
>      This patch was inspired by this proposed change:
>      
>        https://sourceware.org/pipermail/gdb-patches/2022-July/190926.html
>      
>      the goal of that change was to make the info-types tests pass when
>      using Clang as a compiler.  The difference between g++ and Clang, is
>      that g++ will give a (made up) name to an anonymous struct or union
>      that is used in a typedef, Clang doesn't.  The solution proposed in
>      the patch above is to create a third test pattern to be used for
>      C++/Clang, at this point the test script seemed to be getting a little
>      bloated.
>      
>      In this commit I rewrite the test.  Instead of running the 'info
>      types' command and expecting a specific set of lines in a particular
>      order, we now read all the lines from the command output, and place
>      the lines into a dictionary.  We can then query the dictionary to
>      check the all the expected lines are present.
>      
>      Checking for each output line independently has a couple of
>      advantages:
>      
>       1. We no longer care about the output order.  I don't think the
>       ordering is particularly important for this test, so long as all the
>       expected lines are present,
>      
>       2. For lines that are present in both C and C++ we can now share the
>       code to check these patterns, I think this makes it clearer what is
>       going on, and
>      
>       3. It is easy to place a few lines within an `if` block, and so, only
>       check for those lines when using a specific compiler.
>      
>      I've check gdb.base/info-types-c.exp and gdb.base/info-types-c++.exp
>      using both GCC and Clang.
>
> diff --git a/gdb/testsuite/gdb.base/info-types.exp.tcl b/gdb/testsuite/gdb.base/info-types.exp.tcl
> index 2dd9b9e5489..8aa006d0179 100644
> --- a/gdb/testsuite/gdb.base/info-types.exp.tcl
> +++ b/gdb/testsuite/gdb.base/info-types.exp.tcl
> @@ -16,6 +16,113 @@
>   # Check that 'info types' produces the expected output for an inferior
>   # containing a number of different types.
>   
> +
> +# Run the 'info types' command, and place the results into RESULT_VAR,
> +# which should be the name of a variable in the callers scope.
> +#
> +# RESULT_VAR will be cleared, and set to an associative array, the
> +# keys of this associative array will be the line numbers, and the
> +# value for each line number will be a list of the types GDB
> +# understands to be declared on that line.
> +#
> +# Some types don't have a line number for their declartion
> +# (e.g. builtin types), these are placed into a list for the special
> +# line number 'NONE'.
> +#
> +# Finally, only types from the reported in SRCFILE are collected, any
> +# types reported from other files (e.g. libraries linked into the
> +# test) should be ignored.
> +proc collect_output { result_var } {
> +    upvar $result_var result_obj
> +
> +    array set result_obj {}
> +
> +    set collect_lines false
> +    gdb_test_multiple "info types" "" {
> +	-re "^info types\r\n" {
> +	    exp_continue
> +	}
> +
> +	-re "^\r\n" {
> +	    exp_continue
> +	}
> +
> +	-re "^All defined types:\r\n" {
> +	    exp_continue
> +	}
> +
> +	-re "^File (\[^\r\n\]+)\r\n" {
> +	    set filename $expect_out(1,string)
> +	    set collect_lines [regexp [string_to_regexp $::srcfile] $filename]
> +	    exp_continue
> +	}
> +
> +	-re "^($::decimal):\\s+(\[^\r\n\]+);\r\n" {
> +	    set lineno $expect_out(1,string)
> +	    set text $expect_out(2,string)
> +	    if { $collect_lines } {
> +		if { ! [info exists result_obj($lineno)] } {
> +		    set result_obj($lineno) [list]
> +		}
> +		lappend result_obj($lineno) $text
> +	    }
> +	    exp_continue
> +	}
> +
> +	-re "^\\s+(\[^\r\n;\]+)\r\n" {
> +	    set text $expect_out(1,string)
> +	    if { $collect_lines } {
> +		if { ![info exists result_obj(NONE)] } {
> +		    set result_obj(NONE) [list]
> +		}
> +		lappend result_obj(NONE) $text
> +	    }
> +	    exp_continue
> +	}
> +
> +	-re "^$::gdb_prompt $" {
> +	}
> +    }
> +}
> +
> +# RESULT_VAR is the name of a variable in the parent scope that
> +# contains an associative array of results as returned from the
> +# collect_output proc.
> +#
> +# LINE is a line number, or the empty string, and TEXT is the
> +# declaration of a type that GDB should have seen on that line.
> +#
> +# This proc checks in RESULT_VAR for a matching entry to LINE and
> +# TEXT, and, if a matching entry is found, calls pass, otherwise, fail
> +# is called.  The testname used for the pass/fail call is based on
> +# LINE and TEXT.
> +#
> +# If LINE is the empty string then this proc looks for a result
> +# associated with the special line number 'NONE', see collect_output
> +# for more details.
> +proc require_line { result_var line text } {
> +    upvar $result_var result_obj
> +
> +    set testname "check for $text"
> +    if { $line != "" } {
> +	set testname "$testname on line $line"
> +    } else {
> +	set line "NONE"
> +    }
> +
> +    if { ![info exists result_obj($line)] } {
> +	fail $testname
> +	return
> +    }
> +
> +    if { [lsearch -exact $result_obj($line) $text] < 0 } {
> +	fail $testname
> +	return
> +    }
> +
> +    pass $testname
> +}
> +
>   # Run 'info types' test, compiling the test file for language LANG,
>   # which should be either 'c' or 'c++'.
>   proc run_test { lang } {
> @@ -38,79 +145,71 @@ proc run_test { lang } {
>   	return 0
>       }
>   
> -    set file_re "File .*[string_to_regexp $srcfile]:"
> +    # Run 'info types' and place the results in RESULT_OBJ.
> +    collect_output result_obj
> +
> +    # Some results are common to C and C++.  These are the builtin
> +    # types which are not declared on any specific line.
> +    require_line result_obj "" "double"
> +    require_line result_obj "" "float"
> +    require_line result_obj "" "int"
> +
> +    # These typedefs are common to C and C++, but GDB should see a
> +    # specific line number for these type declarations.
> +    require_line result_obj "16" "typedef int my_int_t"
> +    require_line result_obj "17" "typedef float my_float_t"
> +    require_line result_obj "18" "typedef int nested_int_t"
> +    require_line result_obj "19" "typedef float nested_float_t"
>   
>       if { $lang == "c++" } {
> -	set output_lines \
> -	    [list \
> -		 "^All defined types:" \
> -		 ".*" \
> -		 $file_re \
> -		 "98:\[\t \]+CL;" \
> -		 "42:\[\t \]+anon_struct_t;" \
> -		 "65:\[\t \]+anon_union_t;" \
> -		 "21:\[\t \]+baz_t;" \
> -		 "33:\[\t \]+enum_t;" \
> -		 "56:\[\t \]+union_t;" \
> -		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
> -		 "45:\[\t \]+typedef anon_struct_t anon_struct_t;" \
> -		 "68:\[\t \]+typedef anon_union_t anon_union_t;" \
> -		 "28:\[\t \]+typedef baz_t baz;" \
> -		 "31:\[\t \]+typedef baz_t \\* baz_ptr;" \
> -		 "27:\[\t \]+typedef baz_t baz_t;" \
> -		 "\[\t \]+double" \
> -		 "\[\t \]+float" \
> -		 "\[\t \]+int" \
> -		 "103:\[\t \]+typedef CL my_cl;" \
> -		 "38:\[\t \]+typedef enum_t my_enum_t;" \
> -		 "17:\[\t \]+typedef float my_float_t;" \
> -		 "16:\[\t \]+typedef int my_int_t;" \
> -		 "104:\[\t \]+typedef CL \\* my_ptr;" \
> -		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
> -		 "47:\[\t \]+typedef anon_struct_t nested_anon_struct_t;" \
> -		 "70:\[\t \]+typedef anon_union_t nested_anon_union_t;" \
> -		 "30:\[\t \]+typedef baz_t nested_baz;" \
> -		 "29:\[\t \]+typedef baz_t nested_baz_t;" \
> -		 "39:\[\t \]+typedef enum_t nested_enum_t;" \
> -		 "19:\[\t \]+typedef float nested_float_t;" \
> -		 "18:\[\t \]+typedef int nested_int_t;" \
> -		 "62:\[\t \]+typedef union_t nested_union_t;(" \
> -		 "\[\t \]+unsigned int)?" \
> -		 "($|\r\n.*)"]
> +	# These results are specific to 'C++'.
> +	require_line result_obj "21" "baz_t"
> +	require_line result_obj "27" "typedef baz_t baz_t"
> +	require_line result_obj "28" "typedef baz_t baz"
> +	require_line result_obj "29" "typedef baz_t nested_baz_t"
> +	require_line result_obj "30" "typedef baz_t nested_baz"
> +	require_line result_obj "31" "typedef baz_t * baz_ptr"
> +	require_line result_obj "33" "enum_t"
> +	require_line result_obj "38" "typedef enum_t my_enum_t"
> +	require_line result_obj "39" "typedef enum_t nested_enum_t"
> +	require_line result_obj "52" "typedef enum {...} anon_enum_t"
> +	require_line result_obj "54" "typedef enum {...} nested_anon_enum_t"
> +	require_line result_obj "56" "union_t"
> +	require_line result_obj "62" "typedef union_t nested_union_t"
> +	require_line result_obj "98" "CL"
> +	require_line result_obj "103" "typedef CL my_cl"
> +	require_line result_obj "104" "typedef CL * my_ptr"
> +
> +	if { [test_compiler_info "gcc-*"] } {
> +	    # GCC give a name to anonymous structs and unions.  Not
> +	    # all compilers do this, e.g. Clang does not.
> +	    require_line result_obj "42" "anon_struct_t"
> +	    require_line result_obj "45" "typedef anon_struct_t anon_struct_t"
> +	    require_line result_obj "47" "typedef anon_struct_t nested_anon_struct_t"
> +	    require_line result_obj "65" "anon_union_t"
> +	    require_line result_obj "68" "typedef anon_union_t anon_union_t"
> +	    require_line result_obj "70" "typedef anon_union_t nested_anon_union_t"
> +	}
> +
>       } else {
> -	set output_lines \
> -	    [list \
> -		 "^All defined types:" \
> -		 ".*" \
> -		 $file_re \
> -		 "52:\[\t \]+typedef enum {\\.\\.\\.} anon_enum_t;" \
> -		 "45:\[\t \]+typedef struct {\\.\\.\\.} anon_struct_t;" \
> -		 "68:\[\t \]+typedef union {\\.\\.\\.} anon_union_t;" \
> -		 "28:\[\t \]+typedef struct baz_t baz;" \
> -		 "31:\[\t \]+typedef struct baz_t \\* baz_ptr;" \
> -		 "21:\[\t \]+struct baz_t;" \
> -		 "\[\t \]+double" \
> -		 "33:\[\t \]+enum enum_t;" \
> -		 "\[\t \]+float" \
> -		 "\[\t \]+int" \
> -		 "38:\[\t \]+typedef enum enum_t my_enum_t;" \
> -		 "17:\[\t \]+typedef float my_float_t;" \
> -		 "16:\[\t \]+typedef int my_int_t;" \
> -		 "54:\[\t \]+typedef enum {\\.\\.\\.} nested_anon_enum_t;" \
> -		 "47:\[\t \]+typedef struct {\\.\\.\\.} nested_anon_struct_t;" \
> -		 "70:\[\t \]+typedef union {\\.\\.\\.} nested_anon_union_t;" \
> -		 "30:\[\t \]+typedef struct baz_t nested_baz;" \
> -		 "29:\[\t \]+typedef struct baz_t nested_baz_t;" \
> -		 "39:\[\t \]+typedef enum enum_t nested_enum_t;" \
> -		 "19:\[\t \]+typedef float nested_float_t;" \
> -		 "18:\[\t \]+typedef int nested_int_t;" \
> -		 "62:\[\t \]+typedef union union_t nested_union_t;" \
> -		 "56:\[\t \]+union union_t;(" \
> -		 "\[\t \]+unsigned int)?" \
> -		 "($|\r\n.*)"]
> +	# These results are specific to 'C'.
> +	require_line result_obj "21" "struct baz_t"
> +	require_line result_obj "28" "typedef struct baz_t baz"
> +	require_line result_obj "29" "typedef struct baz_t nested_baz_t"
> +	require_line result_obj "30" "typedef struct baz_t nested_baz"
> +	require_line result_obj "31" "typedef struct baz_t * baz_ptr"
> +	require_line result_obj "33" "enum enum_t"
> +	require_line result_obj "38" "typedef enum enum_t my_enum_t"
> +	require_line result_obj "39" "typedef enum enum_t nested_enum_t"
> +	require_line result_obj "45" "typedef struct {...} anon_struct_t"
> +	require_line result_obj "47" "typedef struct {...} nested_anon_struct_t"
> +	require_line result_obj "52" "typedef enum {...} anon_enum_t"
> +	require_line result_obj "54" "typedef enum {...} nested_anon_enum_t"
> +	require_line result_obj "56" "union union_t"
> +	require_line result_obj "62" "typedef union union_t nested_union_t"
> +	require_line result_obj "68" "typedef union {...} anon_union_t"
> +	require_line result_obj "70" "typedef union {...} nested_anon_union_t"
>       }
> -
> -    gdb_test_lines "info types" "" [multi_line {*}$output_lines]
>   }
>   
>   run_test $lang
>

[PATCH v4 14/15] gdb.base/skip.exp: Use finish to exit functions

[Bruno Larsen]

gdb.base/skip.exp was making use of a fixed amount of step commands to
exit some functions.  This caused some problems when using clang to test
GDB, as GDB would need fewer steps to reach the desired spots.  For
instance, when testing in the section "step after disabling 3", the log
looks like this:

    Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    (gdb) step
    bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
    21        return 1;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1
    step
    foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
    42        return 0;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2
    step
    main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34
    34        test_skip_file_and_function ();
    (gdb) step
    test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59
    59        test_skip ();
    (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3
    step
    test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48
    48      }
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4
    step
    test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60
    60        skip1_test_skip_file_and_function ();
    (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5

This shows that the feature is working, but it is not easy to use steps
to test this feature without analyzing all possible outputs, such as
using gdb_step_until_regexp.  Instead, skip.exp now uses finish to leave
functions, synchronizing through compilers and compiler versions.  Some
test names were also changed to be a bit more descriptive.  The new log
looks like this, independently of compiler used:

    Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    (gdb) step
    bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
    21        return 1;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar
    finish
    Run till exit from #0  bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
    main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    Value returned is $2 = 1
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar
    step
    foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
    42        return 0;
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo
    finish
    Run till exit from #0  foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
    main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
    32        x = baz ((bar (), foo ()));
    Value returned is $3 = 0
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo
    step
    34        test_skip_file_and_function ();
    (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
---
 gdb/testsuite/gdb.base/skip.exp | 32 +++++++++++++++-----------------
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp
index e6b660004d9..5b08cde93b7 100644
--- a/gdb/testsuite/gdb.base/skip.exp
+++ b/gdb/testsuite/gdb.base/skip.exp
@@ -100,6 +100,12 @@ if ![runto_main] {
 gdb_test "step" ".*" "step in the main"
 gdb_test "bt" "\\s*\\#0\\s+main.*" "step after all ignored"
 
+proc step_foo_skip_bar_baz {} {
+    gdb_test "step" "foo \\(\\) at.*" "step and skip bar"
+    gdb_test "finish" ".*" "return from bar"
+    gdb_test "step" ".*test_skip_file_and_function.*" "step and skip baz"
+}
+
 # Now remove skip.c from the skiplist.  Our first step should take us
 # into foo(), and our second step should take us to the next line in main().
 
@@ -117,21 +123,19 @@ with_test_prefix "step after deleting 1" {
 	return
     }
 
-    gdb_test "step" "foo \\(\\) at.*" "step 1"
-    gdb_test "step" ".*" "step 2" ; # Return from foo()
-    gdb_test "step" "main \\(\\) at.*" "step 3"
+    step_foo_skip_bar_baz
 }
 
 # Test that we step into foo(), then into bar(), but not into baz().
 proc step_bar_foo_skip_baz {} {
-    gdb_test "step" "bar \\(\\) at.*" "step 1"
-    gdb_test "step" ".*" "step 2"; # Return from bar()
+    gdb_test "step" "bar \\(\\) at.*" "step into bar"
+    gdb_test "finish" ".*" "return from bar"
 
     # With at least gcc 6.5.0 and 9.2.0, we jump once back to main
     # before entering foo here.  If that happens try to step a second
     # time.
     set stepped_again 0
-    gdb_test_multiple "step" "step 3" {
+    gdb_test_multiple "step" "step into foo" {
 	-re -wrap "foo \\(\\) at.*" {
 	    pass $gdb_test_name
 	}
@@ -144,8 +148,8 @@ proc step_bar_foo_skip_baz {} {
 	}
     }
 
-    gdb_test "step" ".*" "step 4"; # Return from foo()
-    gdb_test "step" "main \\(\\) at.*" "step 5"
+    gdb_test "finish" ".*" "Return from foo"
+    gdb_test "step" ".*test_skip_file_and_function.*" "step and skip baz"
 }
 
 # Now disable the skiplist entry for  skip1.c.  We should now
@@ -178,9 +182,7 @@ with_test_prefix "step after enable 3" {
 	return
     }
 
-    gdb_test "step" "foo \\(\\) at.*" "step 1"
-    gdb_test "step" ".*" "step 2"; # Return from foo()
-    gdb_test "step" "main \\(\\) at.*" "step 3"
+    step_foo_skip_bar_baz
 }
 
 # Admin tests (disable,enable,delete).
@@ -249,9 +251,7 @@ with_test_prefix "step using -fi" {
 
     gdb_test_no_output "skip disable"
     gdb_test_no_output "skip enable 5"
-    gdb_test "step" "foo \\(\\) at.*" "step 1"
-    gdb_test "step" ".*" "step 2"; # Return from foo()
-    gdb_test "step" "main \\(\\) at.*" "step 3"
+    step_foo_skip_bar_baz
 }
 
 with_test_prefix "step using -gfi" {
@@ -261,9 +261,7 @@ with_test_prefix "step using -gfi" {
 
     gdb_test_no_output "skip disable"
     gdb_test_no_output "skip enable 6"
-    gdb_test "step" "foo \\(\\) at.*" "step 1"
-    gdb_test "step" ".*" "step 2"; # Return from foo()
-    gdb_test "step" "main \\(\\) at.*" "step 3"
+    step_foo_skip_bar_baz
 }
 
 with_test_prefix "step using -fu for baz" {
-- 
2.31.1

Re: [PATCH v4 14/15] gdb.base/skip.exp: Use finish to exit functions

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> gdb.base/skip.exp was making use of a fixed amount of step commands to

I think s/amount/number/ - amount is for uncountable things, while the
number of steps used can be counted.

> exit some functions.  This caused some problems when using clang to test
> GDB, as GDB would need fewer steps to reach the desired spots.  For
> instance, when testing in the section "step after disabling 3", the log
> looks like this:
>
>     Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
>     32        x = baz ((bar (), foo ()));
>     (gdb) step
>     bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
>     21        return 1;
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 1
>     step
>     foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
>     42        return 0;
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 2
>     step
>     main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:34
>     34        test_skip_file_and_function ();
>     (gdb) step
>     test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:59
>     59        test_skip ();
>     (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 3
>     step
>     test_skip () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:48
>     48      }
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step 4
>     step
>     test_skip_file_and_function () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:60
>     60        skip1_test_skip_file_and_function ();
>     (gdb) FAIL: gdb.base/skip.exp: step after disabling 3: step 5
>
> This shows that the feature is working, but it is not easy to use steps
> to test this feature without analyzing all possible outputs, such as
> using gdb_step_until_regexp.  Instead, skip.exp now uses finish to leave

You mention gdb_step_until_regexp here, which I think is now named just
gdb_step_until.  But more importantly, you mention it, but then don't
actually use this, and its not clear why (from this commit message).

I think it's worth pointing out here that we can't use gdb_step_until
because it would potentially step over the very thing we are trying to
ensure that GDB doesn't do, i.e. call into the skipped function.

> functions, synchronizing through compilers and compiler versions.  Some
> test names were also changed to be a bit more descriptive.  The new log
> looks like this, independently of compiler used:
>
>     Breakpoint 4, main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
>     32        x = baz ((bar (), foo ()));
>     (gdb) step
>     bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
>     21        return 1;
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into bar
>     finish
>     Run till exit from #0  bar () at binutils-gdb/gdb/testsuite/gdb.base/skip1.c:21
>     main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
>     32        x = baz ((bar (), foo ()));
>     Value returned is $2 = 1
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: return from bar
>     step
>     foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
>     42        return 0;
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step into foo
>     finish
>     Run till exit from #0  foo () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:42
>     main () at binutils-gdb/gdb/testsuite/gdb.base/skip.c:32
>     32        x = baz ((bar (), foo ()));
>     Value returned is $3 = 0
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: Return from foo
>     step
>     34        test_skip_file_and_function ();
>     (gdb) PASS: gdb.base/skip.exp: step after disabling 3: step and skip baz
> ---
>  gdb/testsuite/gdb.base/skip.exp | 32 +++++++++++++++-----------------
>  1 file changed, 15 insertions(+), 17 deletions(-)
>
> diff --git a/gdb/testsuite/gdb.base/skip.exp b/gdb/testsuite/gdb.base/skip.exp
> index e6b660004d9..5b08cde93b7 100644
> --- a/gdb/testsuite/gdb.base/skip.exp
> +++ b/gdb/testsuite/gdb.base/skip.exp
> @@ -100,6 +100,12 @@ if ![runto_main] {
>  gdb_test "step" ".*" "step in the main"
>  gdb_test "bt" "\\s*\\#0\\s+main.*" "step after all ignored"
>  
> +proc step_foo_skip_bar_baz {} {

I think this proc should have a comment describing what it's doing.

> +    gdb_test "step" "foo \\(\\) at.*" "step and skip bar"
> +    gdb_test "finish" ".*" "return from bar"
> +    gdb_test "step" ".*test_skip_file_and_function.*" "step and skip baz"
> +}
> +
>  # Now remove skip.c from the skiplist.  Our first step should take us
>  # into foo(), and our second step should take us to the next line in main().
>  
> @@ -117,21 +123,19 @@ with_test_prefix "step after deleting 1" {
>  	return
>      }
>  
> -    gdb_test "step" "foo \\(\\) at.*" "step 1"
> -    gdb_test "step" ".*" "step 2" ; # Return from foo()
> -    gdb_test "step" "main \\(\\) at.*" "step 3"
> +    step_foo_skip_bar_baz
>  }
>  
>  # Test that we step into foo(), then into bar(), but not into baz().
>  proc step_bar_foo_skip_baz {} {
> -    gdb_test "step" "bar \\(\\) at.*" "step 1"
> -    gdb_test "step" ".*" "step 2"; # Return from bar()
> +    gdb_test "step" "bar \\(\\) at.*" "step into bar"
> +    gdb_test "finish" ".*" "return from bar"
>  
>      # With at least gcc 6.5.0 and 9.2.0, we jump once back to main
>      # before entering foo here.  If that happens try to step a second
>      # time.
>      set stepped_again 0
> -    gdb_test_multiple "step" "step 3" {
> +    gdb_test_multiple "step" "step into foo" {
>  	-re -wrap "foo \\(\\) at.*" {
>  	    pass $gdb_test_name
>  	}
> @@ -144,8 +148,8 @@ proc step_bar_foo_skip_baz {} {
>  	}
>      }
>  
> -    gdb_test "step" ".*" "step 4"; # Return from foo()
> -    gdb_test "step" "main \\(\\) at.*" "step 5"
> +    gdb_test "finish" ".*" "Return from foo"
> +    gdb_test "step" ".*test_skip_file_and_function.*" "step and skip baz"
>  }
>  
>  # Now disable the skiplist entry for  skip1.c.  We should now
> @@ -178,9 +182,7 @@ with_test_prefix "step after enable 3" {
>  	return
>      }
>  
> -    gdb_test "step" "foo \\(\\) at.*" "step 1"
> -    gdb_test "step" ".*" "step 2"; # Return from foo()
> -    gdb_test "step" "main \\(\\) at.*" "step 3"
> +    step_foo_skip_bar_baz
>  }
>  
>  # Admin tests (disable,enable,delete).
> @@ -249,9 +251,7 @@ with_test_prefix "step using -fi" {
>  
>      gdb_test_no_output "skip disable"
>      gdb_test_no_output "skip enable 5"
> -    gdb_test "step" "foo \\(\\) at.*" "step 1"
> -    gdb_test "step" ".*" "step 2"; # Return from foo()
> -    gdb_test "step" "main \\(\\) at.*" "step 3"
> +    step_foo_skip_bar_baz
>  }
>  
>  with_test_prefix "step using -gfi" {
> @@ -261,9 +261,7 @@ with_test_prefix "step using -gfi" {
>  
>      gdb_test_no_output "skip disable"
>      gdb_test_no_output "skip enable 6"
> -    gdb_test "step" "foo \\(\\) at.*" "step 1"
> -    gdb_test "step" ".*" "step 2"; # Return from foo()
> -    gdb_test "step" "main \\(\\) at.*" "step 3"
> +    step_foo_skip_bar_baz
>  }

In an earlier version of this patch Pedro raised the concern that if we
remove all of the "step out of a function" tests, then we may remove
some important testing.

With the patch #15 in this series (once that's merged), I think it will
be OK to change this test as you propose.

Thanks,
Andrew


>  
>  with_test_prefix "step using -fu for baz" {
> -- 
> 2.31.1

[PATCH v4 15/15] gdb/testsuite: Add test to step through function epilogue

[Bruno Larsen]

The testsuite implicitly tests GDB's ability to step through epilogues
in multiple tests, without doing it explicitly anywhere.  This is
unfortunate, as clang does not emit epilogue information, so using clang
on our testsuite makes many tests fail.  This patch adds a central,
explicit test for walking through the epilogue so we can safely remove
this from other tests and have them working with clang.

The test created attempts to step through a simple empilogue, an
epilogue that ends on another epilogue, and epilogues leading to other
function calls.
---
 .../gdb.base/step-through-epilogue.c          | 15 ++++
 .../gdb.base/step-through-epilogue.exp        | 86 +++++++++++++++++++
 2 files changed, 101 insertions(+)
 create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
 create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp

diff --git a/gdb/testsuite/gdb.base/step-through-epilogue.c b/gdb/testsuite/gdb.base/step-through-epilogue.c
new file mode 100644
index 00000000000..3e0ea5a2522
--- /dev/null
+++ b/gdb/testsuite/gdb.base/step-through-epilogue.c
@@ -0,0 +1,15 @@
+int multiply (int a, int b){
+    return a*b;
+}
+
+int square (int x){
+    return multiply (x, x);
+}
+
+int main(){
+    int x;
+    x = multiply (1,2);
+    x = square(2);
+    x = multiply (square (1), square (2));
+    return 0;
+}
diff --git a/gdb/testsuite/gdb.base/step-through-epilogue.exp b/gdb/testsuite/gdb.base/step-through-epilogue.exp
new file mode 100644
index 00000000000..762623cf72c
--- /dev/null
+++ b/gdb/testsuite/gdb.base/step-through-epilogue.exp
@@ -0,0 +1,86 @@
+#   Copyright 2022 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+# This test is used to confirm that GDB is able to step, stopping at an
+# epilogue line, then step out of the function.
+
+standard_testfile
+
+if { [get_compiler_info "clang-*"] } {
+    untested "This test can't be used with clang"
+    return
+}
+
+if { [prepare_for_testing "failed to prepare" "skip" \
+			  {step-through-epilogue.c}] } {
+    untested "failed to prepare"
+    return
+}
+
+if { ![runto_main] } {
+    untested "couldn't run to main"
+    return
+}
+
+# Some gcc versions, at least 6.5.0 and 9.2.0, can mess this test by
+# requiring extra steps in a few locations.  We test here and use
+# this knowledge later to decide if the extra steps need to be taken.
+set slow_gcc 0
+if { [test_compiler_info "gcc-6-5-0"] || [test_compiler_info "gcc-9-2-0"]} {
+    set slow_gcc 1
+}
+
+proc step_till_epilogue_multiply {} {
+    gdb_test "step" ".*return a.b;.*" "step into multiply"
+    gdb_test "step" ".*3\\s+\\\}.*" "stop at the epilogue of multiply"
+}
+
+proc step_till_epilogue_square {} {
+    gdb_test "step" ".*return multiply.*" "step into square"
+    step_till_epilogue_multiply
+    gdb_test "step" ".*7\\s+\\\}.*" "stop at epilogue of square"
+}
+
+with_test_prefix "multiply" {
+    step_till_epilogue_multiply
+    gdb_test "step" ".*x = square\\(2\\);" "leave function"
+}
+
+with_test_prefix "square" {
+    step_till_epilogue_square
+    gdb_test "step" ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*"\
+	"leave function"
+}
+
+with_test_prefix "square, first argument" {
+    step_till_epilogue_square
+    if {$slow_gcc} {
+	gdb_test "step"\
+	    ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*"\
+	    "step back to main"
+    }
+}
+with_test_prefix "square, second argument" {
+    step_till_epilogue_square
+    if {$slow_gcc} {
+	gdb_test "step"\
+	    ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*"\
+	    "step back to main"
+    }
+}
+with_test_prefix "multiply with function args" {
+    step_till_epilogue_multiply
+    gdb_test "step" ".*return 0;.*" "leave last function"
+}
-- 
2.31.1

Re: [PATCH v4 15/15] gdb/testsuite: Add test to step through function epilogue

[Andrew Burgess]

Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:

> The testsuite implicitly tests GDB's ability to step through epilogues
> in multiple tests, without doing it explicitly anywhere.  This is
> unfortunate, as clang does not emit epilogue information, so using clang
> on our testsuite makes many tests fail.  This patch adds a central,
> explicit test for walking through the epilogue so we can safely remove
> this from other tests and have them working with clang.

Sounds sensible.

>
> The test created attempts to step through a simple empilogue, an

s/empilogue/epilogue/

> epilogue that ends on another epilogue, and epilogues leading to other
> function calls.
> ---
>  .../gdb.base/step-through-epilogue.c          | 15 ++++
>  .../gdb.base/step-through-epilogue.exp        | 86 +++++++++++++++++++
>  2 files changed, 101 insertions(+)
>  create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
>  create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp
>
> diff --git a/gdb/testsuite/gdb.base/step-through-epilogue.c b/gdb/testsuite/gdb.base/step-through-epilogue.c
> new file mode 100644
> index 00000000000..3e0ea5a2522
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/step-through-epilogue.c

Source files should include a copyright notice at the top, checkout
gdb.base/break.c as an example.

> @@ -0,0 +1,15 @@
> +int multiply (int a, int b){
> +    return a*b;
> +}

Where possible, test source files should follow GNU convention, so:

  int
  multiply (int a, int b)
  {
    ...
  }

if you need to break convention for some reason, maybe having everything
on one line is required by the test, then this should be explained in a
comment.

Also, I notice everything is indented by 4 spaces instead of 2.

> +
> +int square (int x){
> +    return multiply (x, x);
> +}
> +
> +int main(){

Should be 'main (void)' I think.

> +    int x;
> +    x = multiply (1,2);
> +    x = square(2);

Space before '(2)'.

> +    x = multiply (square (1), square (2));
> +    return 0;
> +}
> diff --git a/gdb/testsuite/gdb.base/step-through-epilogue.exp b/gdb/testsuite/gdb.base/step-through-epilogue.exp
> new file mode 100644
> index 00000000000..762623cf72c
> --- /dev/null
> +++ b/gdb/testsuite/gdb.base/step-through-epilogue.exp
> @@ -0,0 +1,86 @@
> +#   Copyright 2022 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with this program.  If not, see <http://www.gnu.org/licenses/>.
> +
> +# This test is used to confirm that GDB is able to step, stopping at an
> +# epilogue line, then step out of the function.
> +
> +standard_testfile
> +
> +if { [get_compiler_info "clang-*"] } {

This should be using 'test_compiler_info' here, the get call doesn't do
what you would expect given its name.

> +    untested "This test can't be used with clang"
> +    return
> +}
> +
> +if { [prepare_for_testing "failed to prepare" "skip" \
> +			  {step-through-epilogue.c}] } {

That's unexpected!  I suspect the use of "skip" here for the binary name
is the result of a cut & paste.  You probably want:

  if { [prepare_for_testing "failed to prepare" $testfile \
  			  {step-through-epilogue.c}] } {
      untested "failed to prepare"
      return
  }

which will result in the test binary being named after the test script.

> +    untested "failed to prepare"
> +    return
> +}
> +
> +if { ![runto_main] } {
> +    untested "couldn't run to main"
> +    return
> +}
> +
> +# Some gcc versions, at least 6.5.0 and 9.2.0, can mess this test by
> +# requiring extra steps in a few locations.  We test here and use
> +# this knowledge later to decide if the extra steps need to be taken.
> +set slow_gcc 0
> +if { [test_compiler_info "gcc-6-5-0"] || [test_compiler_info "gcc-9-2-0"]} {
> +    set slow_gcc 1
> +}
> +
> +proc step_till_epilogue_multiply {} {
> +    gdb_test "step" ".*return a.b;.*" "step into multiply"
> +    gdb_test "step" ".*3\\s+\\\}.*" "stop at the epilogue of multiply"

When you update the source file, you'll find this pattern breaks as the
line number changes.

One trick to avoid placing these line numbers is to add a comment to the
source file, like:

  } /* Epilogue line of multiply.  */

then the pattern can be:

  gdb_test "step" \
    ".*$::decimal\\s+\\\}\[^\r\n\]+Epilogue line of multiply.*" \
    "stop at the epilogue of multiply"

reducing the number of hard-coded line numbers is usually a good thing.

> +}
> +
> +proc step_till_epilogue_square {} {
> +    gdb_test "step" ".*return multiply.*" "step into square"
> +    step_till_epilogue_multiply
> +    gdb_test "step" ".*7\\s+\\\}.*" "stop at epilogue of square"
> +}
> +
> +with_test_prefix "multiply" {
> +    step_till_epilogue_multiply
> +    gdb_test "step" ".*x = square\\(2\\);" "leave function"
> +}
> +
> +with_test_prefix "square" {
> +    step_till_epilogue_square
> +    gdb_test "step" ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*"\
> +	"leave function"
> +}
> +
> +with_test_prefix "square, first argument" {
> +    step_till_epilogue_square
> +    if {$slow_gcc} {
> +	gdb_test "step"\
> +	    ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*"\
> +	    "step back to main"
> +    }

I'm kind-of bothered by the $slow_gcc test.  It feels pretty random that
we only check for those two specific gcc versions.  Plus returning back
to main for that one line doesn't feel that wrong to me, so it seems
like this is less working around a bug in specific compiler versions,
and more just variance in how the debug is emitted.

I wonder if we could make use of gdb_test_multiple to avoid the need for
$slow_gcc?  Something like this completely untested code:

  gcc_test_multiple "step" "step into square" {
    -re -wrap ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*" {
      gdb_send "step\n"
      exp_continue
    }
  
    -re -wrap ".*return multiply.*" {
      pass $gdb_test_name
    }
  }

Of course, that would mean you couldn't then use
step_till_epilogue_square in its current form, as you do next, but maybe
with some refactoring, the above might be made to work?

> +}
> +with_test_prefix "square, second argument" {
> +    step_till_epilogue_square
> +    if {$slow_gcc} {
> +	gdb_test "step"\
> +	    ".*x = multiply \\(square \\(1\\), square \\(2\\)\\);.*"\
> +	    "step back to main"
> +    }
> +}
> +with_test_prefix "multiply with function args" {
> +    step_till_epilogue_multiply
> +    gdb_test "step" ".*return 0;.*" "leave last function"
> +}
> -- 
> 2.31.1

[PIING][PATCH v4 00/15] Clean gdb.base when testing with clang

[Bruno Larsen]

ping!

On 7/20/22 21:44, Bruno Larsen wrote:
> When testing GDB with clang, gdb.base had over 50 more failures than when
> testing with gcc.  Examining the failed tests led to a few clang bugs, a
> few GDB bugs, and many testsuite assumptions that could be changed.
>
> After this patch series, nothing should be changed for testing with gcc,
> and testing with clang should only show non-trivial failures for
> maint.exp and macscp.exp, along with the same GCC failures.
>
> Changes in v4:
>      * Added new test to step through a function's epoligue
>      * renamed gdb_step_until_regexp -> gdb_step_until
>      * small style and wording changes in patches 1 and 2
>      * Dropped patch 3 - no longer necessary
>      * patch 4 was reworked based on Andrew's suggestion
> small note, Andrew has OK'd patched 5 and 6 (currently 4 and 5) in v3;
>
> Changes in v3:
>      * Fixed some issues that only showed up on CXX_FOR_TARGET=clang
>      * rebased on current master
>
> Changes in v2:
>      * Introduced gdb_step_until_regexp, based on Pedro's and Andrew's suggestions
>      * reworked fixes for: skip.exp, skip-solib.exp and msym-bp-shl.exp
>      * Used Pedro's suggestion for call-ar-st
>      * reordered patches slightly
>
> Bruno Larsen (15):
>    gdb/testsuite: introduce gdb_step_until
>    gdb/testsuite: Add a proc to test where compiler links the epilogue
>    Change gdb.base/skip-solib.exp deal with lack of epilogue information
>    gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
>    update gdb.base/info-program.exp to not fail with clang
>    fix gdb.base/access-mem-running.exp for clang testing
>    Fix gdb.base/call-ar-st to work with Clang
>    add xfails to gdb.base/complex-parts.exp when testing with clang
>    gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang
>    explicitly test for stderr in gdb.base/dprintf.exp
>    gdb/testsuite: Update gdb.base/so-impl-ld.exp
>    [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang
>    gdb/testsuite: fix gdb.base/info-types-c++ with clang
>    gdb.base/skip.exp: Use finish to exit functions
>    gdb/testsuite: Add test to step through function epilogue
>
>   gdb/testsuite/gdb.base/access-mem-running.c   |   2 +-
>   gdb/testsuite/gdb.base/call-ar-st.exp         |  13 ++-
>   gdb/testsuite/gdb.base/complex-parts.exp      |   5 +
>   gdb/testsuite/gdb.base/dprintf.exp            |  10 ++
>   gdb/testsuite/gdb.base/info-program.exp       |   2 +-
>   gdb/testsuite/gdb.base/info-types.exp.tcl     | 109 ++++++++++++------
>   gdb/testsuite/gdb.base/jit-elf.exp            |   2 +-
>   gdb/testsuite/gdb.base/msym-bp-shl.exp        |   8 ++
>   gdb/testsuite/gdb.base/nodebug.exp            |  12 +-
>   gdb/testsuite/gdb.base/skip-inline.exp        |  23 ++--
>   gdb/testsuite/gdb.base/skip-solib-lib.c       |   3 +-
>   gdb/testsuite/gdb.base/skip-solib-main.c      |   3 +-
>   gdb/testsuite/gdb.base/skip-solib.exp         |  12 +-
>   gdb/testsuite/gdb.base/skip.exp               |  32 +++--
>   gdb/testsuite/gdb.base/so-impl-ld.exp         |  13 +--
>   gdb/testsuite/gdb.base/solib1.c               |   5 +-
>   .../gdb.base/step-through-epilogue.c          |  15 +++
>   .../gdb.base/step-through-epilogue.exp        |  86 ++++++++++++++
>   gdb/testsuite/lib/gdb.exp                     |  62 ++++++++++
>   19 files changed, 334 insertions(+), 83 deletions(-)
>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp
>

[PINGv2][PATCH v4 00/15] Clean gdb.base when testing with clang

[Bruno Larsen]

ping 2!

On 20/07/2022 21:44, Bruno Larsen wrote:
> When testing GDB with clang, gdb.base had over 50 more failures than when
> testing with gcc.  Examining the failed tests led to a few clang bugs, a
> few GDB bugs, and many testsuite assumptions that could be changed.
>
> After this patch series, nothing should be changed for testing with gcc,
> and testing with clang should only show non-trivial failures for
> maint.exp and macscp.exp, along with the same GCC failures.
>
> Changes in v4:
>      * Added new test to step through a function's epoligue
>      * renamed gdb_step_until_regexp -> gdb_step_until
>      * small style and wording changes in patches 1 and 2
>      * Dropped patch 3 - no longer necessary
>      * patch 4 was reworked based on Andrew's suggestion
> small note, Andrew has OK'd patched 5 and 6 (currently 4 and 5) in v3;
>
> Changes in v3:
>      * Fixed some issues that only showed up on CXX_FOR_TARGET=clang
>      * rebased on current master
>
> Changes in v2:
>      * Introduced gdb_step_until_regexp, based on Pedro's and Andrew's suggestions
>      * reworked fixes for: skip.exp, skip-solib.exp and msym-bp-shl.exp
>      * Used Pedro's suggestion for call-ar-st
>      * reordered patches slightly
>
> Bruno Larsen (15):
>    gdb/testsuite: introduce gdb_step_until
>    gdb/testsuite: Add a proc to test where compiler links the epilogue
>    Change gdb.base/skip-solib.exp deal with lack of epilogue information
>    gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
>    update gdb.base/info-program.exp to not fail with clang
>    fix gdb.base/access-mem-running.exp for clang testing
>    Fix gdb.base/call-ar-st to work with Clang
>    add xfails to gdb.base/complex-parts.exp when testing with clang
>    gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang
>    explicitly test for stderr in gdb.base/dprintf.exp
>    gdb/testsuite: Update gdb.base/so-impl-ld.exp
>    [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang
>    gdb/testsuite: fix gdb.base/info-types-c++ with clang
>    gdb.base/skip.exp: Use finish to exit functions
>    gdb/testsuite: Add test to step through function epilogue
>
>   gdb/testsuite/gdb.base/access-mem-running.c   |   2 +-
>   gdb/testsuite/gdb.base/call-ar-st.exp         |  13 ++-
>   gdb/testsuite/gdb.base/complex-parts.exp      |   5 +
>   gdb/testsuite/gdb.base/dprintf.exp            |  10 ++
>   gdb/testsuite/gdb.base/info-program.exp       |   2 +-
>   gdb/testsuite/gdb.base/info-types.exp.tcl     | 109 ++++++++++++------
>   gdb/testsuite/gdb.base/jit-elf.exp            |   2 +-
>   gdb/testsuite/gdb.base/msym-bp-shl.exp        |   8 ++
>   gdb/testsuite/gdb.base/nodebug.exp            |  12 +-
>   gdb/testsuite/gdb.base/skip-inline.exp        |  23 ++--
>   gdb/testsuite/gdb.base/skip-solib-lib.c       |   3 +-
>   gdb/testsuite/gdb.base/skip-solib-main.c      |   3 +-
>   gdb/testsuite/gdb.base/skip-solib.exp         |  12 +-
>   gdb/testsuite/gdb.base/skip.exp               |  32 +++--
>   gdb/testsuite/gdb.base/so-impl-ld.exp         |  13 +--
>   gdb/testsuite/gdb.base/solib1.c               |   5 +-
>   .../gdb.base/step-through-epilogue.c          |  15 +++
>   .../gdb.base/step-through-epilogue.exp        |  86 ++++++++++++++
>   gdb/testsuite/lib/gdb.exp                     |  62 ++++++++++
>   19 files changed, 334 insertions(+), 83 deletions(-)
>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp
>
-- 
Cheers,
Bruno

[PINGv3][PATCH v4 00/15] Clean gdb.base when testing with clang

[Bruno Larsen]

ping!

On 18/08/2022 09:25, Bruno Larsen wrote:
> ping 2!
>
> On 20/07/2022 21:44, Bruno Larsen wrote:
>> When testing GDB with clang, gdb.base had over 50 more failures than 
>> when
>> testing with gcc.  Examining the failed tests led to a few clang bugs, a
>> few GDB bugs, and many testsuite assumptions that could be changed.
>>
>> After this patch series, nothing should be changed for testing with gcc,
>> and testing with clang should only show non-trivial failures for
>> maint.exp and macscp.exp, along with the same GCC failures.
>>
>> Changes in v4:
>>      * Added new test to step through a function's epoligue
>>      * renamed gdb_step_until_regexp -> gdb_step_until
>>      * small style and wording changes in patches 1 and 2
>>      * Dropped patch 3 - no longer necessary
>>      * patch 4 was reworked based on Andrew's suggestion
>> small note, Andrew has OK'd patched 5 and 6 (currently 4 and 5) in v3;
>>
>> Changes in v3:
>>      * Fixed some issues that only showed up on CXX_FOR_TARGET=clang
>>      * rebased on current master
>>
>> Changes in v2:
>>      * Introduced gdb_step_until_regexp, based on Pedro's and 
>> Andrew's suggestions
>>      * reworked fixes for: skip.exp, skip-solib.exp and msym-bp-shl.exp
>>      * Used Pedro's suggestion for call-ar-st
>>      * reordered patches slightly
>>
>> Bruno Larsen (15):
>>    gdb/testsuite: introduce gdb_step_until
>>    gdb/testsuite: Add a proc to test where compiler links the epilogue
>>    Change gdb.base/skip-solib.exp deal with lack of epilogue information
>>    gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
>>    update gdb.base/info-program.exp to not fail with clang
>>    fix gdb.base/access-mem-running.exp for clang testing
>>    Fix gdb.base/call-ar-st to work with Clang
>>    add xfails to gdb.base/complex-parts.exp when testing with clang
>>    gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang
>>    explicitly test for stderr in gdb.base/dprintf.exp
>>    gdb/testsuite: Update gdb.base/so-impl-ld.exp
>>    [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang
>>    gdb/testsuite: fix gdb.base/info-types-c++ with clang
>>    gdb.base/skip.exp: Use finish to exit functions
>>    gdb/testsuite: Add test to step through function epilogue
>>
>>   gdb/testsuite/gdb.base/access-mem-running.c   |   2 +-
>>   gdb/testsuite/gdb.base/call-ar-st.exp         |  13 ++-
>>   gdb/testsuite/gdb.base/complex-parts.exp      |   5 +
>>   gdb/testsuite/gdb.base/dprintf.exp            |  10 ++
>>   gdb/testsuite/gdb.base/info-program.exp       |   2 +-
>>   gdb/testsuite/gdb.base/info-types.exp.tcl     | 109 ++++++++++++------
>>   gdb/testsuite/gdb.base/jit-elf.exp            |   2 +-
>>   gdb/testsuite/gdb.base/msym-bp-shl.exp        |   8 ++
>>   gdb/testsuite/gdb.base/nodebug.exp            |  12 +-
>>   gdb/testsuite/gdb.base/skip-inline.exp        |  23 ++--
>>   gdb/testsuite/gdb.base/skip-solib-lib.c       |   3 +-
>>   gdb/testsuite/gdb.base/skip-solib-main.c      |   3 +-
>>   gdb/testsuite/gdb.base/skip-solib.exp         |  12 +-
>>   gdb/testsuite/gdb.base/skip.exp               |  32 +++--
>>   gdb/testsuite/gdb.base/so-impl-ld.exp         |  13 +--
>>   gdb/testsuite/gdb.base/solib1.c               |   5 +-
>>   .../gdb.base/step-through-epilogue.c          |  15 +++
>>   .../gdb.base/step-through-epilogue.exp        |  86 ++++++++++++++
>>   gdb/testsuite/lib/gdb.exp                     |  62 ++++++++++
>>   19 files changed, 334 insertions(+), 83 deletions(-)
>>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
>>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp
>>
-- 
Cheers,
Bruno

[PINGv4][PATCH v4 00/15] Clean gdb.base when testing with clang

[Bruno Larsen]

ping!

On 25/08/2022 09:51, Bruno Larsen wrote:
> ping!
>
> On 18/08/2022 09:25, Bruno Larsen wrote:
>> ping 2!
>>
>> On 20/07/2022 21:44, Bruno Larsen wrote:
>>> When testing GDB with clang, gdb.base had over 50 more failures than 
>>> when
>>> testing with gcc.  Examining the failed tests led to a few clang 
>>> bugs, a
>>> few GDB bugs, and many testsuite assumptions that could be changed.
>>>
>>> After this patch series, nothing should be changed for testing with 
>>> gcc,
>>> and testing with clang should only show non-trivial failures for
>>> maint.exp and macscp.exp, along with the same GCC failures.
>>>
>>> Changes in v4:
>>>      * Added new test to step through a function's epoligue
>>>      * renamed gdb_step_until_regexp -> gdb_step_until
>>>      * small style and wording changes in patches 1 and 2
>>>      * Dropped patch 3 - no longer necessary
>>>      * patch 4 was reworked based on Andrew's suggestion
>>> small note, Andrew has OK'd patched 5 and 6 (currently 4 and 5) in v3;
>>>
>>> Changes in v3:
>>>      * Fixed some issues that only showed up on CXX_FOR_TARGET=clang
>>>      * rebased on current master
>>>
>>> Changes in v2:
>>>      * Introduced gdb_step_until_regexp, based on Pedro's and 
>>> Andrew's suggestions
>>>      * reworked fixes for: skip.exp, skip-solib.exp and msym-bp-shl.exp
>>>      * Used Pedro's suggestion for call-ar-st
>>>      * reordered patches slightly
>>>
>>> Bruno Larsen (15):
>>>    gdb/testsuite: introduce gdb_step_until
>>>    gdb/testsuite: Add a proc to test where compiler links the epilogue
>>>    Change gdb.base/skip-solib.exp deal with lack of epilogue 
>>> information
>>>    gdb/testsuite: change gdb.base/nodebug.exp to not fail with clang
>>>    update gdb.base/info-program.exp to not fail with clang
>>>    fix gdb.base/access-mem-running.exp for clang testing
>>>    Fix gdb.base/call-ar-st to work with Clang
>>>    add xfails to gdb.base/complex-parts.exp when testing with clang
>>>    gdb/testsuite: fix gdb.base/msym-bp-shl when running with Clang
>>>    explicitly test for stderr in gdb.base/dprintf.exp
>>>    gdb/testsuite: Update gdb.base/so-impl-ld.exp
>>>    [gdb/testsuite]: fix gdb.base/jit-elf.exp when testing with clang
>>>    gdb/testsuite: fix gdb.base/info-types-c++ with clang
>>>    gdb.base/skip.exp: Use finish to exit functions
>>>    gdb/testsuite: Add test to step through function epilogue
>>>
>>>   gdb/testsuite/gdb.base/access-mem-running.c   |   2 +-
>>>   gdb/testsuite/gdb.base/call-ar-st.exp         |  13 ++-
>>>   gdb/testsuite/gdb.base/complex-parts.exp      |   5 +
>>>   gdb/testsuite/gdb.base/dprintf.exp            |  10 ++
>>>   gdb/testsuite/gdb.base/info-program.exp       |   2 +-
>>>   gdb/testsuite/gdb.base/info-types.exp.tcl     | 109 
>>> ++++++++++++------
>>>   gdb/testsuite/gdb.base/jit-elf.exp            |   2 +-
>>>   gdb/testsuite/gdb.base/msym-bp-shl.exp        |   8 ++
>>>   gdb/testsuite/gdb.base/nodebug.exp            |  12 +-
>>>   gdb/testsuite/gdb.base/skip-inline.exp        |  23 ++--
>>>   gdb/testsuite/gdb.base/skip-solib-lib.c       |   3 +-
>>>   gdb/testsuite/gdb.base/skip-solib-main.c      |   3 +-
>>>   gdb/testsuite/gdb.base/skip-solib.exp         |  12 +-
>>>   gdb/testsuite/gdb.base/skip.exp               |  32 +++--
>>>   gdb/testsuite/gdb.base/so-impl-ld.exp         |  13 +--
>>>   gdb/testsuite/gdb.base/solib1.c               |   5 +-
>>>   .../gdb.base/step-through-epilogue.c          |  15 +++
>>>   .../gdb.base/step-through-epilogue.exp        |  86 ++++++++++++++
>>>   gdb/testsuite/lib/gdb.exp                     |  62 ++++++++++
>>>   19 files changed, 334 insertions(+), 83 deletions(-)
>>>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.c
>>>   create mode 100644 gdb/testsuite/gdb.base/step-through-epilogue.exp
>>>
-- 
Cheers,
Bruno