[PATCH v2 14/17] Allow other results in DW_TAG_entry_point test

[Tom Tromey <tom@tromey.com>]

DW_TAG_entry_point is implemented by adding a new LOC_BLOCK symbol --
that is, another function symbol.  However, the test case assumes that
"bt" will never pick this symbol.

This assumption seems unwarranted to me, and in fact this test will
regress with the debug-names target board after the .debug_names
rewrite.

This patch changes the test to allow either answer in the backtrace.
If only the main entry point is desired, then it seems that more work
must be done to handle DW_TAG_entry_point properly, as nothing
currently guarantees this property.
---
 gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
index c0c7a7ca542..632a31111a2 100644
--- a/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
+++ b/gdb/testsuite/gdb.dwarf2/dw2-entry-points.exp
@@ -207,7 +207,10 @@ if ![runto_main] {
 gdb_breakpoint "*fooso"
 gdb_continue_to_breakpoint "foo_so"
 
+# Note that because DW_TAG_entry_point is entered as a LOC_BLOCK
+# symbol, exactly which symbol is shown in the stack trace depends on
+# which symbol gdb happens to find first in the lookup.
 gdb_test "bt" [multi_line \
-		    "#0.*${hex} in foo \\(J=1, K=0\\).*" \
+		    "#0.*${hex} in (foo|fooso) \\(J=1, K=0\\).*" \
 		    "#1.*${hex} in prog \\(\\).*" \
 ] "bt fooso"

-- 
2.43.0