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

Message ID 20240117-debug-names-fix-v2-14-dbd5971a9c31@tromey.com
State New
Headers
Series Rewrite .debug_names reader and writer |

Checks

Context Check Description
linaro-tcwg-bot/tcwg_gdb_build--master-aarch64 success Testing passed
linaro-tcwg-bot/tcwg_gdb_build--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-arm success Testing passed
linaro-tcwg-bot/tcwg_gdb_check--master-aarch64 success Testing passed

Commit Message

Tom Tromey Jan. 17, 2024, 4:39 p.m. UTC
  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(-)
  

Patch

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"