This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Run process-dies-while-detaching.exp with SW watchpoint
- From: Yao Qi <qiyaoltc at gmail dot com>
- To: gdb-patches at sourceware dot org
- Date: Tue, 23 Aug 2016 15:47:36 +0100
- Subject: Run process-dies-while-detaching.exp with SW watchpoint
- Authentication-results: sourceware.org; auth=none
Hi,
I see the following fail when I run tests on some ARM board without
HW watchpoint support,
(gdb) watch globalvar^M
Watchpoint 2: globalvar^M
(gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: detach: watchpoint: watch globalvar
I think we should run test_detach_watch with both HW watchpoint and SW
watchpoint. I modified it, as the patch shown below, but the
test_detach_watch with SW watchpoint causes some test fails even on
x86_64,
Thread 12 "process-dies-wh" hit Temporary breakpoint 3, 0x00002aaaaafaf2d0 in _exit () from /lib/x86_64-linux-gnu/libc.so.6^M
(gdb) PASS: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint hw=0: continue to breakpoint: _exit
continue^M
Continuing.^M
Cannot find user-level thread for LWP 2363: generic error^M
(gdb) FAIL: gdb.threads/process-dies-while-detaching.exp: single-process: continue: watchpoint hw=0: continue
When the error is thrown, the stack backtrace is
(gdb) bt 10
#0 thread_from_lwp (ptid=...) at /home/yao/SourceCode/gnu/gdb/git/gdb/linux-thread-db.c:356
#1 0x0000000000460fb4 in thread_db_wait (ops=<optimised out>, ptid=..., ourstatus=0x7fff702c0510, options=1)
at /home/yao/SourceCode/gnu/gdb/git/gdb/linux-thread-db.c:1146
#2 0x00000000005b69cd in delegate_wait (self=<optimised out>, arg1=..., arg2=<optimised out>, arg3=<optimised out>)
at /home/yao/SourceCode/gnu/gdb/git/gdb/target-delegates.c:116
#3 0x00000000005c5bb4 in target_wait (ptid=..., status=status@entry=0x7fff702c0510, options=options@entry=1)
at /home/yao/SourceCode/gnu/gdb/git/gdb/target.c:2289
#4 0x0000000000578269 in do_target_wait (ptid=..., status=status@entry=0x7fff702c0510, options=1) at /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3641
#5 0x0000000000583a1b in fetch_inferior_event (client_data=<optimised out>) at /home/yao/SourceCode/gnu/gdb/git/gdb/infrun.c:3952
#6 0x0000000000598cd5 in gdb_wait_for_event (block=block@entry=0) at /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:859
#7 0x0000000000598ee5 in gdb_do_one_event () at /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:322
#8 0x0000000000598f55 in start_event_loop () at /home/yao/SourceCode/gnu/gdb/git/gdb/event-loop.c:371
#9 0x0000000000592d18 in captured_command_loop (data=data@entry=0x0) at /home/yao/SourceCode/gnu/gdb/git/gdb/main.c:324
and the "ourstatus" got from beneath->to_wait is
(gdb) p *ourstatus
$1 = {kind = TARGET_WAITKIND_STOPPED, value = {integer = 5, sig = GDB_SIGNAL_TRAP, related_pid = {pid = 5, lwp = 0, tid = 0},
execd_pathname = 0x5 <error: Cannot access memory at address 0x5>, syscall_number = 5}}
looks linux-nat target thinks the thread is stopped, but thread-db can't
find the thread. Is it a known problem (in gdb or glibc)?
--
Yao (齐尧)
diff --git a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
index 52dc8dd..39cba31 100644
--- a/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
+++ b/gdb/testsuite/gdb.threads/process-dies-while-detaching.exp
@@ -209,10 +209,12 @@ proc test_detach {multi_process cmd} {
}
}
-# Same as test_detach, except set a watchpoint before detaching.
+# Same as test_detach, except set a watchpoint before detaching. HW
+# is true if hardware watchpoint is used.
-proc test_detach_watch {multi_process cmd} {
- with_test_prefix "watchpoint" {
+proc test_detach_watch {hw multi_process cmd} {
+
+ with_test_prefix "watchpoint hw=$hw" {
global binfile decimal
clean_restart ${binfile}
@@ -230,15 +232,25 @@ proc test_detach_watch {multi_process cmd} {
gdb_continue_to_breakpoint "child_function" ".*"
}
+ if { ! $hw } {
+ gdb_test_no_output "set can-use-hw-watchpoints 0" ""
+ }
# Set a watchpoint in the child.
- gdb_test "watch globalvar" ".* watchpoint $decimal: globalvar"
+ gdb_test "watch globalvar" ".*\[Ww\]atchpoint $decimal: globalvar"
# Continue to the _exit breakpoint. This arms the watchpoint
# registers in all threads. Detaching will thus need to clear
# them out, and handle the case of the thread disappearing
# while doing that (on targets that need to detach from each
# thread individually).
- continue_to_exit_bp
+ if { ! $hw } {
+ # Software watchpoint is quite slow.
+ with_timeout_factor 10 {
+ continue_to_exit_bp
+ }
+ } else {
+ continue_to_exit_bp
+ }
do_detach $multi_process $cmd
}
@@ -313,7 +325,11 @@ proc do_test {multi_process cmd} {
}
test_detach $multi_process $cmd
- test_detach_watch $multi_process $cmd
+ if { ![target_info exists gdb,no_hardware_watchpoints] } {
+ test_detach_watch 1 $multi_process $cmd
+ }
+ test_detach_watch 0 $multi_process $cmd
+
test_detach_killed_outside $multi_process $cmd
}