aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.guile
diff options
context:
space:
mode:
authorPedro Alves <pedro@palves.net>2020-09-02 23:20:45 +0100
committerPedro Alves <pedro@palves.net>2020-10-13 22:28:48 +0100
commit8abd8ee8c878f52469896c716732a974e6abeebe (patch)
tree5e1db9402352352b8cecff31397b0731a1712326 /gdb/testsuite/gdb.guile
parentf71e6719e1c2dde20e3286ca7c4969f1c10eb523 (diff)
downloadgdb-8abd8ee8c878f52469896c716732a974e6abeebe.zip
gdb-8abd8ee8c878f52469896c716732a974e6abeebe.tar.gz
gdb-8abd8ee8c878f52469896c716732a974e6abeebe.tar.bz2
gdb/testsuite/: Use -qualified in runto_main / mi_runto_main
In some runtimes, there may be a "main" function in some class or namespace. The breakpoint created by runto_main may therefore have unexpected locations on some other functions than the actual main. These breakpoint locations can unexpectedly get hit during tests and lead to failures. I saw this while playing with AMD's ROCm toolchain -- I wrote a board file to run the testsuite against device kernels. There, the runtime calls a "main" function before the device kernel code is reached: Thread 4 "bit_extract" hit Breakpoint 1, 0x00007ffeea140960 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1 (gdb) bt #0 0x00007ffeea140960 in lld::elf::LinkerDriver::main(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1 #1 0x00007ffeea2257a5 in lld::elf::link(llvm::ArrayRef<char const*>, bool, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1 #2 0x00007ffeea1bc374 in COMGR::linkWithLLD(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1 #3 0x00007ffeea1bfb09 in COMGR::InProcessDriver::execute(llvm::ArrayRef<char const*>) () from /opt/rocm/lib/libamd_comgr.so.1 #4 0x00007ffeea1c4da9 in COMGR::AMDGPUCompiler::linkToExecutable() () from /opt/rocm/lib/libamd_comgr.so.1 #5 0x00007ffeea1fde20 in dispatchCompilerAction(amd_comgr_action_kind_s, COMGR::DataAction*, COMGR::DataSet*, COMGR::DataSet*, llvm::raw_ostream&) () from /opt/rocm/lib/libamd_comgr.so.1 #6 0x00007ffeea203a87 in amd_comgr_do_action () from /opt/rocm/lib/libamd_comgr.so.1 ... To avoid that, pass "qualified" to runto, in runto_main, so that gdb_breakpoint ends up creating a breakpoint with -qualified. This avoids creating breakpoints locations for other unrelated "main" functions. Note: I first tried making runto itself use "-qualified", but that caused regressions in the gdb.ada/ tests, which use runto without specifying the whole fully-qualified function name (i.e., without the package). So I end up restricting the -qualified to runto_main/mi_runto_main. The gdb.base/ui-redirect.exp change is necessary because that testcase is looking at what "save breakpoint" generates. gdb/testsuite/ChangeLog: * gdb.base/ui-redirect.exp: Expect "break -qualified main" in saved breakpoints file. * gdb.guile/scm-breakpoint.exp: Expect "-qualified main" when inspecting breakpoint list. * lib/gdb.exp (runto_main): Add "qualified" to options. * lib/mi-support.exp (mi_runto_helper): Add 'qualified' parameter, and handle it. (mi_runto_main): Pass 1 as qualified argument. Change-Id: I51468359ab0a518f05f7c0394c97f7e33b45fe69
Diffstat (limited to 'gdb/testsuite/gdb.guile')
-rw-r--r--gdb/testsuite/gdb.guile/scm-breakpoint.exp2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/testsuite/gdb.guile/scm-breakpoint.exp b/gdb/testsuite/gdb.guile/scm-breakpoint.exp
index 7545392..3bcd5c8 100644
--- a/gdb/testsuite/gdb.guile/scm-breakpoint.exp
+++ b/gdb/testsuite/gdb.guile/scm-breakpoint.exp
@@ -43,7 +43,7 @@ proc test_bkpt_basic { } {
gdb_scm_test_silent_cmd "guile (define blist (breakpoints))" \
"get breakpoint list 1"
gdb_test "guile (print (car blist))" \
- "<gdb:breakpoint #1 BP_BREAKPOINT enabled noisy hit:1 ignore:0 @main>" \
+ "<gdb:breakpoint #1 BP_BREAKPOINT enabled noisy hit:1 ignore:0 @-qualified main>" \
"check main breakpoint"
gdb_test "guile (print (breakpoint-location (car blist)))" \
"main" "check main breakpoint location"