[PATCH] Fix a latent bug in dw2-ranges-overlap.exp

[PATCH] Fix a latent bug in dw2-ranges-overlap.exp

[Tom Tromey]

dw2-ranges-overlap.exp creates a program where a psymtab has two
address ranges, and a function without debug info whose address is
between these two ranges.  Then it sets a breakpoint on this function
and runs to it, expecting that the language should remain "auto; c"
when stopped.

However, this test case also has a "main" function described (briefly)
in the DWARF, and this function is given language C++.  Also, a
breakpoint stop sets the current language to the language that was
used when setting the breakpoint.

My new DWARF scanner decides that this "main" is the main program and
sets the current language to C++ at startup, causing this test to
fail.

This patch fixes the test in a simple way, by introducing a new
function that takes the place of "main" in the DWARF.  I think this
still exercises the original problem, but also avoids problems with my
branch.

It seemed safe to me to submit this separately.
---
 gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.c   |  9 ++++++++-
 gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.exp | 10 +++++-----
 2 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.c b/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.c
index 5e69e4aa52b..e3d70f471dc 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.c
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.c
@@ -28,9 +28,16 @@ foo (int a)
   return bar (a * 2) + 3;
 }
 
+int
+quux (int a)
+{
+  asm ("quux_label: .globl quux_label");
+  return foo (a);
+}
+
 int
 main (void)
 {
   asm ("main_label: .globl main_label");
-  return foo (5) + 1;
+  return quux (5) + 1;
 }
diff --git a/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.exp b/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.exp
index 972ab762a27..5da60bf3a33 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-ranges-overlap.exp
@@ -44,10 +44,10 @@ Dwarf::assemble $asm_file {
     declare_labels ranges_label
 
     # Find start address and length for our functions.
-    set main_func \
-	[function_range main [list ${srcdir}/${subdir}/$srcfile]]
     set foo_func \
 	[function_range foo [list ${srcdir}/${subdir}/$srcfile]]
+    set quux_func \
+	[function_range quux [list ${srcdir}/${subdir}/$srcfile]]
     set bar_func \
 	[function_range bar [list ${srcdir}/${subdir}/$srcfile]]
 
@@ -59,15 +59,15 @@ Dwarf::assemble $asm_file {
 	} {
 	    subprogram {
 		{external 1 flag}
-		{name main}
+		{name quux}
 	    }
 	}
     }
 
     ranges {is_64 [is_64_target]} {
 	ranges_label: sequence {
-	    base [lindex $main_func 0]
-	    range 0 [lindex $main_func 1]
+	    base [lindex $quux_func 0]
+	    range 0 [lindex $quux_func 1]
 	    base [lindex $bar_func 0]
 	    range 0 [lindex $bar_func 1]
 	}
-- 
2.31.1

Re: [PATCH] Fix a latent bug in dw2-ranges-overlap.exp

[Tom Tromey]

Tom> My new DWARF scanner decides that this "main" is the main program and
Tom> sets the current language to C++ at startup, causing this test to
Tom> fail.

Tom> This patch fixes the test in a simple way, by introducing a new
Tom> function that takes the place of "main" in the DWARF.  I think this
Tom> still exercises the original problem, but also avoids problems with my
Tom> branch.

I'm going to check this in now.

Tom

Re: [PATCH] Fix a latent bug in dw2-ranges-overlap.exp

[Tom de Vries]

On 8/23/21 10:13 PM, Tom Tromey wrote:
> Tom> My new DWARF scanner decides that this "main" is the main program and
> Tom> sets the current language to C++ at startup, causing this test to
> Tom> fail.
> 
> Tom> This patch fixes the test in a simple way, by introducing a new
> Tom> function that takes the place of "main" in the DWARF.  I think this
> Tom> still exercises the original problem, but also avoids problems with my
> Tom> branch.
> 

In the patch introducing the test-case, it was mentioned:
...
The dwarf assembly test-case mimics the scenario described above, and
reproduces the FAIL with and without -readnow, for both mentioned OS
configurations.
...

Already before this commit, that no longer seems to be the case: when
reverting the fix, the test-case only fails with target board readnow.

Anyway, I've confirmed that after this commit, reverting the fix still
make the test-case fail with target board readnow.

Thanks,
- Tom