[v2,14/17] Allow other results in DW_TAG_entry_point test
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
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(-)
@@ -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"