348 commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
Don Breazeal
|
7868401b7b |
PR remote/19496, interrupted syscall in forking-threads-plus-bkpt
This patch addresses "fork:Interrupted system call" (or wait:) failures in gdb.threads/forking-threads-plus-breakpoint.exp. The test program spawns ten threads, each of which do ten fork/waitpid sequences. The cause of the problem was that when one of the fork children exited before the corresponding fork parent could initiate its waitpid for that child, a SIGCHLD and/or SIGSTOP was delivered and interrupted a fork or waitpid in another thread. The fix was to wrap the system calls in a loop to retry the call if it was interrupted, like: do { pid = fork (); } while (pid == -1 && errno == EINTR); Since this is a Linux-only test I figure it is OK to use errno and EINTR. I tried a number of alternative fixes using SIG_IGN, SA_RESTART, pthread_sigblock, and bsd_signal, but none of these worked as well. Tested on Nios II Linux target with x86 Linux host. gdb/testsuite/ChangeLog: 2016-03-16 Don Breazeal <donb@codesourcery.com> * gdb.threads/forking-threads-plus-breakpoint.c (thread_forks): Retry fork and waitpid on interrupted system call errors. * gdb.threads/forking-threads-plus-breakpoint.exp: (do_test): Use with_timeout_factor to increase timeout to 90. |
||
Pedro Alves
|
00dbd492e4 |
More "Program" -> "Thread NN received signal" testsuite adjustment
These tests should have been adjusted by
|
||
Pedro Alves
|
1e903e3203 |
Fix gdb.threads/watchpoint-fork*.c compilation
This testcase currently fails to compile on Fedora 23: .../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c: In function 'start': .../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70:11: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaration] i = pthread_yield (); ^ .../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c: In function 'forkoff': .../src/gdb/testsuite/gdb.threads/watchpoint-fork-child.c:114:8: warning: implicit declaration of function 'pthread_yield' [-Wimplicit-function-declaratio n] i = pthread_yield (); ^ /tmp/ccUkNIsI.o: In function `start': .../src/gdb/testsuite/gdb.threads/watchpoint-fork-mt.c:70: undefined reference to `pthread_yield' (...) collect2: error: ld returned 1 exit status UNSUPPORTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: Couldn't compile watchpoint-fork-child.c: unrecognized error UNTESTED: gdb.threads/watchpoint-fork.exp: child: multithreaded: watchpoint-fork.exp testcase .../src/gdb/testsuite/gdb.threads/watchpoint-fork.exp completed i The glibc manual says, on _GNU_SOURCE: "You should define these macros by using ‘#define’ preprocessor directives at the top of your source code files. These directives must come before any #include of a system header file." I instead put it in the header all the .c files of the testcase must include anyway. gdb/testsuite/ChangeLog: 2016-03-01 Pedro Alves <palves@redhat.com> * gdb.threads/watchpoint-fork-child.c: Include "watchpoint-fork.h" before anything else. * gdb.threads/watchpoint-fork-mt.c: Likewise. Don't define _GNU_SOURCE here. * gdb.threads/watchpoint-fork-st.c: Include "watchpoint-fork.h" before anything else. * gdb.threads/watchpoint-fork.h: Define _GNU_SOURCE. |
||
Yao Qi
|
40fb20d037 |
Set breakpoint condition-evaluation in forking-threads-plus-breakpoint.exp
Proc do_test in forking-threads-plus-breakpoint.exp has an argument cond_bp_target, but the test doesn't use it to set "breakpoint condition-evaluation", which is an oversight in the test. This patch fixes it by setting "breakpoint condition-evaluation" per $cond_bp_target. gdb/testsuite: 2016-02-18 Yao Qi <yao.qi@linaro.org> * gdb.threads/forking-threads-plus-breakpoint.exp (do_test): Set "set breakpoint condition-evaluation" per $cond_bp_target. |
||
Don Breazeal
|
4041ed7780 |
PR remote/19496, internal err forking-threads-plus-bkpt
This patch fixes an internal error that occurs in gdb.threads/forking-threads-plus-breakpoint.exp: /blah/binutils-gdb/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 3170.3170 In default_thread_address_space, find_inferior_ptid couldn't find 3170.3170 because it had been overwritten in inferior_appeared, called as follows: inferior_appeared remote_add_inferior remote_notice_new_inferior remote_update_thread_list The cause of the problem was the following sequence of events: * GDB knows only about the main thread * the first fork event is reported to GDB, saved as pending_event * qXfer:threads:read gets the threads from the remote. remove_new_fork_children id's the fork child from the pending event and removes it from the list reported to GDB. All the rest of the threads, including the fork parent, are added to the GDB thread list. * GDB stops all the threads. All the stop events are pushed onto the stop reply queue behind the pending fork event. The fork waitstatus is saved in the fork parent thread's pending status field thread_info.suspend. * remote_wait_ns calls queued_stop_reply and process_stop_reply to remove the fork event from the front of the stop reply queue and save event information in the thread_info structure for the fork parent thread. Unfortunately, none of the information saved in this way is the fork-specific information. * A subsequent qXfer:threads:read packet gets the thread list including the fork parent and fork child. remove_new_fork_children checks the thread list to see if there is a fork parent, doesn't find one, checks the stop reply queue for a pending fork event, doesn't find one, and allows the fork child thread to be reported to GDB before the fork event has been handled. remote_update_thread_list calls remote_notice_new_thread and overwrites the current (main) thread in inferior_appeared. So the fork event has been reported out of target_wait but it was left pending on the infrun side (infrun.c:save_waitstatus). IOW, the fork event hasn't been processed by handle_inferior_event yet, so it hasn't made it to tp->pending_follow yet. The fix is to check thread_info.suspend along with the thread_info.pending_follow in remote.c:remove_new_fork_children, to prevent premature reporting of the fork child thread creation. gdb/ChangeLog: PR remote/19496 * remote.c (remove_new_fork_children): Check for pending fork status in thread_info.suspend. gdb/testsuite/ChangeLog: PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (do_test): Remove kfail for PR remote/19496. |
||
Simon Marchi
|
2151ccc56c |
Always organize test artifacts in a directory hierarchy
When running tests in parallel, each test puts its generated files in a different directory, under "outputs". I think it would be nice if it was always the case, as it would isolate the test cases a bit more. An artifact created by a test wouldn't get overwritten by another test. Also, it makes it easier to clean up. A lot of executables are left all over the place because their names do not appear in gdb.*/Makefile. If everything is in "outputs", then we just have to delete that directory (which we already do). At the same time it makes the gdb.foo directories and their Makefiles useless in the build directory, since they are pretty much only used for cleaning. What do you think? gdb/testsuite/ChangeLog: * Makefile.in (ALL_SUBDIRS): Remove. (clean mostlyclean): Do not recurse in ALL_SUBDIRS. (distclean maintainer-clean realclean): Likewise. * configure.ac (AC_OUTPUT): Remove gdb.*/Makefile. * configure: Regenerate. * gdb.ada/Makefile.in: Delete. * gdb.arch/Makefile.in: Likewise. * gdb.asm/Makefile.in: Likewise. * gdb.base/Makefile.in: Likewise. * gdb.btrace/Makefile.in: Likewise. * gdb.cell/Makefile.in: Likewise. * gdb.compile/Makefile.in: Likewise. * gdb.cp/Makefile.in: Likewise. * gdb.disasm/Makefile.in: Likewise. * gdb.dlang/Makefile.in: Likewise. * gdb.dwarf2/Makefile.in: Likewise. * gdb.fortran/Makefile.in: Likewise. * gdb.gdb/Makefile.in: Likewise. * gdb.go/Makefile.in: Likewise. * gdb.guile/Makefile.in: Likewise. * gdb.java/Makefile.in: Likewise. * gdb.linespec/Makefile.in: Likewise. * gdb.mi/Makefile.in: Likewise. * gdb.modula2/Makefile.in: Likewise. * gdb.multi/Makefile.in: Likewise. * gdb.objc/Makefile.in: Likewise. * gdb.opencl/Makefile.in: Likewise. * gdb.opt/Makefile.in: Likewise. * gdb.pascal/Makefile.in: Likewise. * gdb.perf/Makefile.in: Likewise. * gdb.python/Makefile.in: Likewise. * gdb.reverse/Makefile.in: Likewise. * gdb.server/Makefile.in: Likewise. * gdb.stabs/Makefile.in: Likewise. * gdb.threads/Makefile.in: Likewise. * gdb.trace/Makefile.in: Likewise. * gdb.xml/Makefile.in: Likewise. * lib/gdb.exp (make_gdb_parallel_path): Add check for GDB_PARALLEL. (standard_output_file): Remove check for GDB_PARALLEL, always return path in outputs/$subdir/$testname. |
||
Pedro Alves
|
6b2e4f10ae |
Test gdb.threads/forking-threads-plus-breakpoint.exp with displaced stepping off
This exposes the internal error Don mentioned in PR19496: (1) internal error -- gdb/target.c:2713: internal-error: Can't determine the current address space of thread More analysis here: https://sourceware.org/ml/gdb-patches/2016-01/msg00685.html The (now kfailed) internal error looks like: continue & Continuing. (gdb) PASS: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: continue & [New Thread 2846.2847] (...) [New Thread 2867.2867] /home/pedro/gdb/mygit/src/gdb/target.c:2723: internal-error: Can't determine the current address space of thread Thread 2846.2846 A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) KFAIL: gdb.threads/forking-threads-plus-breakpoint.exp: cond_bp_target=1: detach_on_fork=on: displaced=off: inferior 1 exited (GDB internal error) (PRMS: remote/19496) Resyncing due to internal error. gdb/testsuite/ChangeLog: 2016-02-01 Pedro Alves <palves@redhat.com> PR remote/19496 * gdb.threads/forking-threads-plus-breakpoint.exp (displaced_stepping_supported): New global. (probe_displaced_stepping_support): New procedure. (do_test): Add 'displaced' parameter, and use it. (top level): Check for displaced stepping support. Add displaced stepping on/off testing axis. |
||
Pedro Alves
|
f1da4b11ee |
Move foreach_with_prefix to lib/gdb.exp
gdb/testsuite/ChangeLog: 2016-01-25 Pedro Alves <palves@redhat.com> * gdb.base/step-sw-breakpoint-adjust-pc.exp (foreach_with_prefix): Delete, moved to lib/gdb.exp. * gdb.threads/forking-threads-plus-breakpoint.exp (foreach_with_prefix): Likewise. * gdb.threads/process-dies-while-handling-bp.exp (foreach_with_prefix): Likewise. * lib/gdb.exp (foreach_with_prefix): New procedure. |
||
Pedro Alves
|
f303dbd60d |
Fix PR threads/19422 - show which thread caused stop
This commit changes GDB like this: - Program received signal SIGINT, Interrupt. + Thread 1 "main" received signal SIGINT, Interrupt. - Breakpoint 1 at 0x40087a: file threads.c, line 87. + Thread 3 "bar" hit Breakpoint 1 at 0x40087a: file threads.c, line 87. ... once the program goes multi-threaded. Until GDB sees a second thread spawn, the output is still the same as before, per the discussion back in 2012: https://www.sourceware.org/ml/gdb/2012-11/msg00010.html This helps non-stop mode, where you can't easily tell which thread hit a breakpoint or received a signal: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 19362) "main" (running) 2 Thread 0x7ffff7fc0700 (LWP 19366) "foo" (running) 3 Thread 0x7ffff77bf700 (LWP 19367) "bar" (running) (gdb) Program received signal SIGUSR1, User defined signal 1. 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 92 lll_wait_tid (pd->tid); (gdb) b threads.c:87 Breakpoint 1 at 0x40087a: file threads.c, line 87. (gdb) Breakpoint 1, thread_function1 (arg=0x1) at threads.c:87 87 usleep (1); /* Loop increment. */ The best the user can do is run "info threads" and try to figure things out. It actually also affects all-stop mode, in case of "handle SIG print nostop": ... Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. Program received signal SIGUSR1, User defined signal 1. ... The above doesn't give any clue that these were different threads getting the SIGUSR1 signal. I initially thought of lowercasing "breakpoint" in "Thread 3 hit Breakpoint 1" but then after trying it I realized that leaving "Breakpoint" uppercase helps the eye quickly find the relevant information. It's also easier to implement not showing anything about threads until the program goes multi-threaded this way. Here's a larger example session in non-stop mode: (gdb) c -a& Continuing. (gdb) interrupt -a (gdb) Thread 1 "main" stopped. 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 92 lll_wait_tid (pd->tid); Thread 2 "foo" stopped. 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) Thread 3 "bar" stopped. 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) b threads.c:87 Breakpoint 4 at 0x40087a: file threads.c, line 87. (gdb) b threads.c:67 Breakpoint 5 at 0x400811: file threads.c, line 67. (gdb) c -a& Continuing. (gdb) Thread 3 "bar" hit Breakpoint 4, thread_function1 (arg=0x1) at threads.c:87 87 usleep (1); /* Loop increment. */ Thread 2 "foo" hit Breakpoint 5, thread_function0 (arg=0x0) at threads.c:68 68 (*myp) ++; info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 31957) "main" (running) 2 Thread 0x7ffff7fc0700 (LWP 31961) "foo" thread_function0 (arg=0x0) at threads.c:68 3 Thread 0x7ffff77bf700 (LWP 31962) "bar" thread_function1 (arg=0x1) at threads.c:87 (gdb) shell kill -SIGINT 31957 (gdb) Thread 1 "main" received signal SIGINT, Interrupt. 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 92 lll_wait_tid (pd->tid); info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 31957) "main" 0x0000003616a09237 in pthread_join (threadid=140737353877248, thread_return=0x7fffffffd5b8) at pthread_join.c:92 2 Thread 0x7ffff7fc0700 (LWP 31961) "foo" thread_function0 (arg=0x0) at threads.c:68 3 Thread 0x7ffff77bf700 (LWP 31962) "bar" thread_function1 (arg=0x1) at threads.c:87 (gdb) t 2 [Switching to thread 2, Thread 0x7ffff7fc0700 (LWP 31961)] #0 thread_function0 (arg=0x0) at threads.c:68 68 (*myp) ++; (gdb) catch syscall Catchpoint 6 (any syscall) (gdb) c& Continuing. (gdb) Thread 2 "foo" hit Catchpoint 6 (call to syscall nanosleep), 0x0000003615ebc6ed in nanosleep () at ../sysdeps/unix/syscall-template.S:81 81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) I'll work on documentation next if this looks agreeable. This patch applies on top of the star wildcards thread IDs series: https://sourceware.org/ml/gdb-patches/2016-01/msg00291.html For convenience, I've pushed this to the users/palves/show-which-thread-caused-stop branch. gdb/doc/ChangeLog: 2016-01-18 Pedro Alves <palves@redhat.com> * gdb.texinfo (Threads): Mention that GDB displays the ID and name of the thread that hit a breakpoint or received a signal. gdb/ChangeLog: 2016-01-18 Pedro Alves <palves@redhat.com> * NEWS: Mention that GDB now displays the ID and name of the thread that hit a breakpoint or received a signal. * break-catch-sig.c (signal_catchpoint_print_it): Use maybe_print_thread_hit_breakpoint. * break-catch-syscall.c (print_it_catch_syscall): Likewise. * break-catch-throw.c (print_it_exception_catchpoint): Likewise. * breakpoint.c (maybe_print_thread_hit_breakpoint): New function. (print_it_catch_fork, print_it_catch_vfork, print_it_catch_solib) (print_it_catch_exec, print_it_ranged_breakpoint) (print_it_watchpoint, print_it_masked_watchpoint, bkpt_print_it): Use maybe_print_thread_hit_breakpoint. * breakpoint.h (maybe_print_thread_hit_breakpoint): Declare. * gdbthread.h (show_thread_that_caused_stop): Declare. * infrun.c (print_signal_received_reason): Print which thread received signal. * thread.c (show_thread_that_caused_stop): New function. gdb/testsuite/ChangeLog: 2016-01-18 Pedro Alves <palves@redhat.com> * gdb.base/async-shell.exp: Adjust expected output. * gdb.base/dprintf-non-stop.exp: Adjust expected output. * gdb.base/siginfo-thread.exp: Adjust expected output. * gdb.base/watchpoint-hw-hit-once.exp: Adjust expected output. * gdb.java/jnpe.exp: Adjust expected output. * gdb.threads/clone-new-thread-event.exp: Adjust expected output. * gdb.threads/continue-pending-status.exp: Adjust expected output. * gdb.threads/leader-exit.exp: Adjust expected output. * gdb.threads/manythreads.exp: Adjust expected output. * gdb.threads/pthreads.exp: Adjust expected output. * gdb.threads/schedlock.exp: Adjust expected output. * gdb.threads/siginfo-threads.exp: Adjust expected output. * gdb.threads/signal-command-multiple-signals-pending.exp: Adjust expected output. * gdb.threads/signal-delivered-right-thread.exp: Adjust expected output. * gdb.threads/sigthread.exp: Adjust expected output. * gdb.threads/watchpoint-fork.exp: Adjust expected output. |
||
Pedro Alves
|
663f6d42f4 |
Add $_gthread convenience variable
This commit adds a new $_gthread convenience variable, that is like $_thread, but holds the current thread's global thread id. gdb/ChangeLog: 2016-01-13 Pedro Alves <palves@redhat.com> * NEWS: Mention $_gthread. * gdbthread.h (struct thread_info) <global_num>: Mention $_gthread. * thread.c (thread_num_make_value_helper): New function. (thread_id_make_value): Delete. (thread_id_per_inf_num_make_value, global_thread_id_make_value): New. (thread_funcs): Adjust. (gthread_funcs): New. (_initialize_thread): Register $_gthread variable. gdb/testsuite/ChangeLog: 2016-01-13 Pedro Alves <palves@redhat.com> * gdb.base/default.exp: Expect $_gthread as well. * gdb.multi/tids.exp: Test $_gthread. * gdb.threads/thread-specific.exp: Test $_gthread. gdb/doc/ChangeLog: 2016-01-13 Pedro Alves <palves@redhat.com> * gdb.texinfo (Threads): Document the $_gthread convenience variable. (Convenience Vars): Likewise. |
||
Pedro Alves
|
5d5658a1d3 |
Per-inferior/Inferior-qualified thread IDs
This commit changes GDB to track thread numbers per-inferior. Then, if you're debugging multiple inferiors, GDB displays "inferior-num.thread-num" instead of just "thread-num" whenever it needs to display a thread: (gdb) info inferiors Num Description Executable 1 process 6022 /home/pedro/gdb/tests/threads * 2 process 6037 /home/pedro/gdb/tests/threads (gdb) info threads Id Target Id Frame 1.1 Thread 0x7ffff7fc2740 (LWP 6022) "threads" (running) 1.2 Thread 0x7ffff77c0700 (LWP 6028) "threads" (running) 1.3 Thread 0x7ffff7fc2740 (LWP 6032) "threads" (running) 2.1 Thread 0x7ffff7fc1700 (LWP 6037) "threads" (running) 2.2 Thread 0x7ffff77c0700 (LWP 6038) "threads" (running) * 2.3 Thread 0x7ffff7fc2740 (LWP 6039) "threads" (running) (gdb) ... (gdb) thread 1.1 [Switching to thread 1.1 (Thread 0x7ffff7fc2740 (LWP 8155))] (gdb) ... etc. You can still use "thread NUM", in which case GDB infers you're referring to thread NUM of the current inferior. The $_thread convenience var and Python's InferiorThread.num attribute are remapped to the new per-inferior thread number. It's a backward compatibility break, but since it only matters when debugging multiple inferiors, I think it's worth doing. Because MI thread IDs need to be a single integer, we keep giving threads a global identifier, _in addition_ to the per-inferior number, and make MI always refer to the global thread IDs. IOW, nothing changes from a MI frontend's perspective. Similarly, since Python's Breakpoint.thread and Guile's breakpoint-thread/set-breakpoint-thread breakpoint methods need to work with integers, those are adjusted to work with global thread IDs too. Follow up patches will provide convenient means to access threads' global IDs. To avoid potencially confusing users (which also avoids updating much of the testsuite), if there's only one inferior and its ID is "1", IOW, the user hasn't done anything multi-process/inferior related, then the "INF." part of thread IDs is not shown. E.g,.: (gdb) info inferiors Num Description Executable * 1 process 15275 /home/pedro/gdb/tests/threads (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40 (gdb) add-inferior Added inferior 2 (gdb) info threads Id Target Id Frame * 1.1 Thread 0x7ffff7fc1740 (LWP 15275) "threads" main () at threads.c:40 (gdb) No regressions on x86_64 Fedora 20. gdb/ChangeLog: 2016-01-13 Pedro Alves <palves@redhat.com> * NEWS: Mention that thread IDs are now per inferior and global thread IDs. * Makefile.in (SFILES): Add tid-parse.c. (COMMON_OBS): Add tid-parse.o. (HFILES_NO_SRCDIR): Add tid-parse.h. * ada-tasks.c: Adjust to use ptid_to_global_thread_id. * breakpoint.c (insert_breakpoint_locations) (remove_threaded_breakpoints, bpstat_check_breakpoint_conditions) (print_one_breakpoint_location, set_longjmp_breakpoint) (check_longjmp_breakpoint_for_call_dummy) (set_momentary_breakpoint): Adjust to use global IDs. (find_condition_and_thread, watch_command_1): Use parse_thread_id. (until_break_command, longjmp_bkpt_dtor) (breakpoint_re_set_thread, insert_single_step_breakpoint): Adjust to use global IDs. * dummy-frame.c (pop_dummy_frame_bpt): Adjust to use ptid_to_global_thread_id. * elfread.c (elf_gnu_ifunc_resolver_stop): Likewise. * gdbthread.h (struct thread_info): Rename field 'num' to 'global_num. Add new fields 'per_inf_num' and 'inf'. (thread_id_to_pid): Rename thread_id_to_pid to global_thread_id_to_ptid. (pid_to_thread_id): Rename to ... (ptid_to_global_thread_id): ... this. (valid_thread_id): Rename to ... (valid_global_thread_id): ... this. (find_thread_id): Rename to ... (find_thread_global_id): ... this. (ALL_THREADS, ALL_THREADS_BY_INFERIOR): Declare. (print_thread_info): Add comment. * tid-parse.h: New file. * tid-parse.c: New file. * infcmd.c (step_command_fsm_prepare) (step_command_fsm_should_stop): Adjust to use the global thread ID. (until_next_command, until_next_command) (finish_command_fsm_should_stop): Adjust to use the global thread ID. (attach_post_wait): Adjust to check the inferior number too. * inferior.h (struct inferior) <highest_thread_num>: New field. * infrun.c (handle_signal_stop) (insert_exception_resume_breakpoint) (insert_exception_resume_from_probe): Adjust to use the global thread ID. * record-btrace.c (record_btrace_open): Use global thread IDs. * remote.c (process_initial_stop_replies): Also consider the inferior number. * target.c (target_pre_inferior): Clear the inferior's highest thread num. * thread.c (clear_thread_inferior_resources): Adjust to use the global thread ID. (new_thread): New inferior parameter. Adjust to use it. Set both the thread's global ID and the thread's per-inferior ID. (add_thread_silent): Adjust. (find_thread_global_id): New. (find_thread_id): Make static. Adjust to rename. (valid_thread_id): Rename to ... (valid_global_thread_id): ... this. (pid_to_thread_id): Rename to ... (ptid_to_global_thread_id): ... this. (thread_id_to_pid): Rename to ... (global_thread_id_to_ptid): ... this. Adjust. (first_thread_of_process): Adjust. (do_captured_list_thread_ids): Adjust to use global thread IDs. (should_print_thread): New function. (print_thread_info): Rename to ... (print_thread_info_1): ... this, and add new show_global_ids parameter. Handle it. Iterate over inferiors. (print_thread_info): Reimplement as wrapper around print_thread_info_1. (show_inferior_qualified_tids): New function. (print_thread_id): Use it. (tp_array_compar): Compare inferior numbers too. (thread_apply_command): Use tid_range_parser. (do_captured_thread_select): Use parse_thread_id. (thread_id_make_value): Adjust. (_initialize_thread): Adjust "info threads" help string. * varobj.c (struct varobj_root): Update comment. (varobj_create): Adjust to use global thread IDs. (value_of_root_1): Adjust to use global_thread_id_to_ptid. * windows-tdep.c (display_tib): No longer accept an argument. * cli/cli-utils.c (get_number_trailer): Make extern. * cli/cli-utils.h (get_number_trailer): Declare. (get_number_const): Adjust documentation. * mi/mi-cmd-var.c (mi_cmd_var_update_iter): Adjust to use global thread IDs. * mi/mi-interp.c (mi_new_thread, mi_thread_exit) (mi_on_normal_stop, mi_output_running_pid, mi_on_resume): * mi/mi-main.c (mi_execute_command, mi_cmd_execute): Likewise. * guile/scm-breakpoint.c (gdbscm_set_breakpoint_thread_x): Likewise. * python/py-breakpoint.c (bppy_set_thread): Likewise. * python/py-finishbreakpoint.c (bpfinishpy_init): Likewise. * python/py-infthread.c (thpy_get_num): Add comment and return the per-inferior thread ID. (thread_object_getset): Update comment of "num". gdb/testsuite/ChangeLog: 2016-01-07 Pedro Alves <palves@redhat.com> * gdb.base/break.exp: Adjust to output changes. * gdb.base/hbreak2.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/watch_thread_num.exp: Likewise. * gdb.linespec/keywords.exp: Likewise. * gdb.multi/info-threads.exp: Likewise. * gdb.threads/thread-find.exp: Likewise. * gdb.multi/tids.c: New file. * gdb.multi/tids.exp: New file. gdb/doc/ChangeLog: 2016-01-07 Pedro Alves <palves@redhat.com> * gdb.texinfo (Threads): Document per-inferior thread IDs, qualified thread IDs, global thread IDs and thread ID lists. (Set Watchpoints, Thread-Specific Breakpoints): Adjust to refer to thread IDs. (Convenience Vars): Document the $_thread convenience variable. (Ada Tasks): Adjust to refer to thread IDs. (GDB/MI Async Records, GDB/MI Thread Commands, GDB/MI Ada Tasking Commands, GDB/MI Variable Objects): Update to mention global thread IDs. * guile.texi (Breakpoints In Guile) <breakpoint-thread/set-breakpoint-thread breakpoint>: Mention global thread IDs instead of thread IDs. * python.texi (Threads In Python): Adjust documentation of InferiorThread.num. (Breakpoint.thread): Mention global thread IDs instead of thread IDs. |
||
Pedro Alves
|
b05b120205 |
Reapply: List inferiors/threads/pspaces in ascending order
[This reapplies a change that was accidentally reverted with c0ecb95f3d.] Before: (gdb) info threads Id Target Id Frame 3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30 2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60 * 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92 After: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92 2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60 3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30 gdb/doc/ChangeLog: 2015-11-24 Pedro Alves <palves@redhat.com> PR 17539 * gdb.texinfo (Inferiors and Programs): Adjust "maint info program-spaces" example to ascending order listing. (Threads): Adjust "info threads" example to ascending order listing. (Forks): Adjust "info inferiors" example to ascending order listing. gdb/ChangeLog: 2015-11-24 Pedro Alves <palves@redhat.com> PR 17539 * inferior.c (add_inferior_silent): Append the new inferior to the end of the list. * progspace.c (add_program_space): Append the new pspace to the end of the list. * thread.c (new_thread): Append the new thread to the end of the list. gdb/testsuite/ChangeLog: 2015-11-24 Pedro Alves <palves@redhat.com> PR 17539 * gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and threads in ascending order. * gdb.base/foll-fork.exp: Likewise. * gdb.base/foll-vfork.exp: Likewise. * gdb.base/multi-forks.exp: Likewise. * gdb.mi/mi-nonstop.exp: Likewise. * gdb.mi/mi-nsintrall.exp: Likewise. * gdb.multi/base.exp: Likewise. * gdb.multi/multi-arch.exp: Likewise. * gdb.python/py-inferior.exp: Likewise. * gdb.threads/break-while-running.exp: Likewise. * gdb.threads/execl.exp: Likewise. * gdb.threads/gcore-thread.exp: Likewise. * gdb.threads/info-threads-cur-sal.exp: Likewise. * gdb.threads/kill.exp: Likewise. * gdb.threads/linux-dp.exp: Likewise. * gdb.threads/multiple-step-overs.exp: Likewise. * gdb.threads/next-bp-other-thread.exp: Likewise. * gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise. * gdb.threads/step-over-lands-on-breakpoint.exp: Likewise. * gdb.threads/step-over-trips-on-watchpoint.exp: Likewise. * gdb.threads/thread-find.exp: Likewise. * gdb.threads/tls.exp: Likewise. * lib/mi-support.exp (mi_reverse_list): Delete. (mi_check_thread_states): No longer reverse list. |
||
Jan Kratochvil
|
c0ecb95f3d |
testsuite: Fix false FAILs on too long base directory
I was getting gu (print arg0)^M = 0x7fffffffdafb "/unsafebuild-x86_64-redhat-linux-gnu/gdb/testsuite.unix.-m64/outputs/gdb.guile/scm-value/scm-"...^M (gdb) FAIL: gdb.guile/scm-value.exp: verify dereferenced value python print (arg0)^M 0x7fffffffdafd "/unsafebuild-x86_64-redhat-linux-gnu/gdb/testsuite.unix.-m64/outputs/gdb.python/py-value/py-v"...^M (gdb) FAIL: gdb.python/py-value.exp: verify dereferenced value and also: (gdb) p argv[0]^M $2 = 0x7fffffffd832 "/home/jkratoch/redhat/gdb-test-", 'x' <repeats 169 times>...^M (gdb) FAIL: gdb.guile/scm-value.exp: argv[0] should be available on this target gdb/testsuite/ChangeLog 2016-01-11 Jan Kratochvil <jan.kratochvil@redhat.com> * gdb.guile/scm-value.exp (test_value_in_inferior): Set print elements and repeats to unlimited. * gdb.python/py-value.exp: Likewise. * lib/gdb.exp (gdb_has_argv0): Save and temporarily set print elements and repeats to unlimited. |
||
Joel Brobecker
|
618f726fcb |
GDB copyright headers update after running GDB's copyright.py script.
gdb/ChangeLog: Update year range in copyright notice of all files. |
||
Simon Marchi
|
3ca22649a6 |
Remove HP-UX references fom testsuite
This patch removes all special cases for HP-UX, for which support has been removed earlier, that I found in the testsuite. Note that the hppa architecture != HP-UX, since other OSes can run on hppa, so I tried to leave everything that is not HP-UX specific. Two complete tests were completely HP-UX specific, so I removed them. I ran the testsuite on Linux x86-64, native and native-gdbserver, and noticed no regressions. gdb/testsuite/ChangeLog: * gdb.asm/asm-source.exp: Remove HP-UX references. * gdb.base/annota1.exp: Likewise. * gdb.base/annota3.exp: Likewise. * gdb.base/attach.exp: Likewise. * gdb.base/bigcore.exp: Likewise. * gdb.base/break.exp: Likewise. * gdb.base/call-ar-st.exp: Likewise. * gdb.base/callfuncs.exp: Likewise. * gdb.base/catch-fork-static.exp: Likewise. * gdb.base/display.exp: Likewise. * gdb.base/foll-exec-mode.exp: Likewise. * gdb.base/foll-exec.exp: Likewise. * gdb.base/foll-fork.exp: Likewise. * gdb.base/foll-vfork.exp: Likewise. * gdb.base/funcargs.exp: Likewise. * gdb.base/hbreak2.exp: Likewise. * gdb.base/inferior-died.exp: Likewise. * gdb.base/interrupt.exp: Likewise. * gdb.base/multi-forks.exp: Likewise. * gdb.base/nodebug.exp: Likewise. * gdb.base/sepdebug.exp: Likewise. * gdb.base/solib1.c: Likewise. * gdb.base/step-test.exp: Likewise. * gdb.mi/non-stop.c: Likewise. * gdb.mi/pthreads.c: Likewise. * gdb.multi/bkpt-multi-exec.ex: Likewise. * gdb.threads/pthreads.c: Likewise. * gdb.threads/staticthreads.exp: Likewise. * lib/future.exp: Likewise. * lib/gdb.exp: Likewise. * gdb.base/so-indr-cl.c: Remove. * gdb.base/so-indr-cl.exp: Likewise. * gdb.base/solib.c: Likewise. * gdb.base/solib.exp: Likewise. * gdb.base/solib2.c: Likewise. |
||
Sandra Loosemore
|
87a3a92c46 |
Skip tests that send ctrl-c to GDB if nointerrupts target property is set.
2015-12-14 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.base/completion.exp: Skip tests that interrupt GDB with ctrl-C if nointerrupts target property is set. * gdb.base/double-prompt-target-event-error.exp: Likewise. * gdb.base/paginate-after-ctrl-c-running.exp: Likewise. * gdb.base/paginate-bg-execution.exp: Likewise. * gdb.base/paginate-execution-startup.exp: Likewise. * gdb.base/random-signal.exp: Likewise. * gdb.base/range-stepping.exp: Likewise. * gdb.cp/annota2.exp: Likewise. * gdb.cp/annota3.exp: Likewise. * gdb.gdb/selftest.exp: Likewise. * gdb.threads/continue-pending-status.exp: Likewise. * gdb.threads/leader-exit.exp: Likewise. * gdb.threads/manythreads.exp: Likewise. * gdb.threads/pthreads.exp: Likewise. * gdb.threads/schedlock.exp: Likewise. * gdb.threads/sigthread.exp: Likewise. |
||
Don Breazeal
|
a8f077dc25 |
Target remote mode fork and exec test updates
This patch updates tests for fork and exec events in target remote mode. In the majority of cases this was a simple matter of removing some code that disabled the test for target remote. In a few cases the test needed to be disabled; in those cases the gdb_protocol was checked instead of using the [is_remote target] etc. In a couple of cases we needed to use clean_restart, since target remote doesn't support the run command, and in one case we had to modify an expect expression to allow for a "multiprocess-style" ptid. Tested with the patch that implemented target remote mode fork and exec event support. gdb/testsuite/ChangeLog: * gdb.base/execl-update-breakpoints.exp (main): Enable for target remote. * gdb.base/foll-exec-mode.exp (main): Disable for target remote. * gdb.base/foll-exec.exp (main): Enable for target remote. * gdb.base/foll-fork.exp (main): Likewise. * gdb.base/foll-vfork.exp (main): Likewise. * gdb.base/multi-forks.exp (main): Likewise, and use clean_restart. (proc continue_to_exit_bp_loc): Use clean_restart. * gdb.base/pie-execl.exp (main): Disable for target remote. * gdb.base/watch-vfork.exp (main): Enable for target remote. * gdb.mi/mi-nsthrexec.exp (main): Likewise. * gdb.threads/execl.exp (main): Likewise. * gdb.threads/fork-child-threads.exp (main): Likewise. * gdb.threads/fork-plus-threads.exp (main): Disable for target remote. * gdb.threads/fork-thread-pending.exp (main): Enable for target remote. * gdb.threads/linux-dp.exp (check_philosopher_stack): Allow pid.tid style ptids, instead of just tid. * gdb.threads/thread-execl.exp (main): Enable for target remote. * gdb.threads/watchpoint-fork.exp (main): Likewise. * gdb.trace/report.exp (use_collected_data): Allow pid.tid style ptids, instead of just tid. |
||
Pedro Alves
|
f2faf941ae |
Implement TARGET_WAITKIND_NO_RESUMED in the remote protocol
Testing with "maint set target-non-stop on" causes regressions in tests that rely on TARGET_WAITKIND_NO_RESUMED, which isn't modelled on the RSP. In real all-stop, gdbserver detects the situation and reporst error to GDB, and so the tests (e.g., gdb.threads/no-unwaited-for-left.exp) at fail quickly. But with "maint set target-non-stop on", GDB instead hangs forever waiting for a stop reply that never comes, and so the tests take longer to time out. This adds a new "N" stop reply packet that maps 1-1 to TARGET_WAITKIND_NO_RESUMED. gdb/ChangeLog: 2015-11-30 Pedro Alves <palves@redhat.com> PR 14618 * NEWS (New remote packets): Mention the N stop reply. * remote.c (remote_protocol_features): Add "no-resumed" entry. (remote_query_supported): Report no-resumed+ support. (remote_parse_stop_reply): Handle 'N'. (process_stop_reply): Handle TARGET_WAITKIND_NO_RESUMED. (remote_wait_as): Handle 'N' / TARGET_WAITKIND_NO_RESUMED. (_initialize_remote): Register "set/show remote no-resumed-stop-reply" commands. gdb/doc/ChangeLog: 2015-11-30 Pedro Alves <palves@redhat.com> PR 14618 * gdb.texinfo (Stop Reply Packets): Document the N stop reply. (Remote Configuration): Add the "set/show remote no-resumed-stop-reply" to the available settings table. (General Query Packets): Document the "no-resumed" qSupported feature. gdb/gdbserver/ChangeLog: 2015-11-30 Pedro Alves <palves@redhat.com> PR 14618 * linux-low.c (linux_wait_1): If the last resumed thread is gone, report TARGET_WAITKIND_NO_RESUMED. * remote-utils.c (prepare_resume_reply): Handle TARGET_WAITKIND_NO_RESUMED. * server.c (report_no_resumed): New global. (handle_query) <qSupported>: Handle "no-resumed+". Report "no-resumed+" support. (resume): When the target reports TARGET_WAITKIND_NO_RESUMED, only return error if the client doesn't support no-resumed events. (push_stop_notification): New function. (handle_target_event): Use it. Report TARGET_WAITKIND_NO_RESUMED events if the client supports them. gdb/testsuite/ChangeLog: 2015-11-30 Pedro Alves <palves@redhat.com> * gdb.threads/no-unwaited-for-left.exp: Remove setup_kfail calls. |
||
Simon Marchi
|
f6512a69cd |
Add test for thread names
I couldn't find a test that verified the thread name functionality, so I created a new one. A target board can define gdb,no_thread_names if it doesn't support thread names and wants to skip the tests that uses them. This test has been made with Linux in mind. Not all platforms use pthread_setname_np to set the thread name, but some #ifdefs can be added later in order to support other platforms. Tested on x86-64 Ubuntu 14.04, native and remote. gdb/testsuite/ChangeLog: * gdb.threads/names.exp: New file. * gdb.threads/names.c: New file. * README: Mention gdb,no_thread_names. |
||
Pedro Alves
|
7e0aa6aa99 |
List inferiors/threads/pspaces in ascending order
Before: (gdb) info threads Id Target Id Frame 3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30 2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60 * 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92 After: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fc5740 (LWP 29030) 0x0000003b37209237 in pthread_join (threadid=140737353893632, thread_return=0x0) at pthread_join.c:92 2 Thread 0x7ffff7fc4700 (LWP 29034) 0x000000000040087b in child_function_2 (arg=0x0) at foo.c:60 3 Thread 0x7ffff77c3700 (LWP 29035) callme () at foo.c:30 gdb/doc/ChangeLog: 2015-11-24 Pedro Alves <palves@redhat.com> PR 17539 * gdb.texinfo (Inferiors and Programs): Adjust "maint info program-spaces" example to ascending order listing. (Threads): Adjust "info threads" example to ascending order listing. (Forks): Adjust "info inferiors" example to ascending order listing. gdb/ChangeLog: 2015-11-24 Pedro Alves <palves@redhat.com> PR 17539 * inferior.c (add_inferior_silent): Append the new inferior to the end of the list. * progspace.c (add_program_space): Append the new pspace to the end of the list. * thread.c (new_thread): Append the new thread to the end of the list. gdb/testsuite/ChangeLog: 2015-11-24 Pedro Alves <palves@redhat.com> PR 17539 * gdb.base/foll-exec-mode.exp: Adjust to GDB listing inferiors and threads in ascending order. * gdb.base/foll-fork.exp: Likewise. * gdb.base/foll-vfork.exp: Likewise. * gdb.base/multi-forks.exp: Likewise. * gdb.mi/mi-nonstop.exp: Likewise. * gdb.mi/mi-nsintrall.exp: Likewise. * gdb.multi/base.exp: Likewise. * gdb.multi/multi-arch.exp: Likewise. * gdb.python/py-inferior.exp: Likewise. * gdb.threads/break-while-running.exp: Likewise. * gdb.threads/execl.exp: Likewise. * gdb.threads/gcore-thread.exp: Likewise. * gdb.threads/info-threads-cur-sal.exp: Likewise. * gdb.threads/kill.exp: Likewise. * gdb.threads/linux-dp.exp: Likewise. * gdb.threads/multiple-step-overs.exp: Likewise. * gdb.threads/next-bp-other-thread.exp: Likewise. * gdb.threads/step-bg-decr-pc-switch-thread.exp: Likewise. * gdb.threads/step-over-lands-on-breakpoint.exp: Likewise. * gdb.threads/step-over-trips-on-watchpoint.exp: Likewise. * gdb.threads/thread-find.exp: Likewise. * gdb.threads/tls.exp: Likewise. * lib/mi-support.exp (mi_reverse_list): Delete. (mi_check_thread_states): No longer reverse list. |
||
Yao Qi
|
4081c0f122 |
Simplify gdb.threads/wp-replication.exp on counting HW watchpoints
Nowadays, test gdb.threads/wp-replication.exp uses a while loop to repeatedly insert HW watchpoint, resume and check no error message coming out, in order to count HW watchpoints There are some drawbacks in this way, - the loop could be endless. I think this is use to making trouble to S/390, since we had such comment # Some targets (like S/390) behave as though supporting # unlimited hardware watchpoints. In this case we just take a # safe exit out of the loop. I hit this today too because a GDB internal error is triggered on "continue" in the loop, and $done is 0 invariantly, so the loop can't end. - the code counting hardware watchpoint is too complicated. We can use "set breakpoint always-inserted on" to get the result of inserting HW watchpoint without resuming the inferior. In this way, watch_count_done and empty_cycle in c file is no longer needed. In this patch, I change to use "set breakpoint always-inserted on" trick, and only iterate $NR_THREADS times, to count the HW watchpoint. In this way, the loop can't be endless, and GDB doesn't need to resume the inferior. gdb/testsuite: 2015-10-30 Yao Qi <yao.qi@linaro.org> * gdb.threads/wp-replication.c (watch_count_done): Remove. (empty_cycle): Remove. (main): Don't call empty_cycle. Don't use watch_count_done. * gdb.threads/wp-replication.exp: Don't set breakpoint on empty_cycle. Rewrite the code counting HW watchpoints. |
||
Pedro Alves
|
1ed415e2b9 |
non-stop-fair-events.exp slower on software single-step && !displ-step targets
On software single-step targets that don't support displaced stepping, threads keep hitting each other's single-step breakpoints, and then GDB needs to pause all threads to step past those. The end result is that progress in the main thread will be slower and it may take a bit longer for the signal to be queued. This patch bumps the timeout on such targets. gdb/testsuite/ChangeLog: 2015-09-16 Pedro Alves <palves@redhat.com> Sandra Loosemore <sandra@codesourcery.com> * gdb.threads/non-stop-fair-events.c (timeout): New global. (SECONDS): Redefine. (main): Call pthread_kill and alarm early. * gdb.threads/non-stop-fair-events.exp: Probe displaced stepping support. (test): If the target can't hardware step and doesn't support displaced stepping, increase the timeout. |
||
Pedro Alves
|
d136eff549 |
Make it easier to debug non-stop-fair-events.exp
If we enable infrun debug running this test, it quickly fails with a full expect buffer. That can be simply handled with a couple exp_continues. As it's annoying to hack this every time we need to debug the test, this patch adds bits to enable debugging support easily, with a one-line change. And then, if any iteration of the test fails, we end up with a long cascade of time outs. Just bail out when we see the first fail. gdb/testsuite/ 2015-09-16 Pedro Alves <palves@redhat.com> * gdb.threads/non-stop-fair-events.exp (gdb_test_no_anchor) (enable_debug): New procedures. (test): Use them. Bail out if waiting for threads fails. (top level): Bail out if a test fails. |
||
Philippe Waroquiers
|
5382cfab61 |
Fix PR/18564 - regression in showing __thread so extern variable
Ensure tls variable address is not relocated, as the msym addr is an offset in the thread local storage of the shared library/object. |
||
Pedro Alves
|
d15dcecdee |
Fix gdb.threads/non-ldr-exc-3.exp race
gdb.threads/non-ldr-exc-3.exp is sometimes failing like this:
[Switching to Thread 6831.6832]
Breakpoint 2, thread_execler (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/non-ldr-exc-3.c:41
41 if (execl (image, image, argv1, NULL) == -1) /* break-here */
PASS: gdb.threads/non-ldr-exc-3.exp: lock-sched=on,non-stop=off: continue to breakpoint
(gdb) set scheduler-locking on
(gdb) FAIL: gdb.threads/non-ldr-exc-3.exp: lock-sched=on,non-stop=off: set scheduler-locking on
The problem is that the gdb_test_multiple is missing the prompt
anchor. The problem was introduced by
|
||
Don Breazeal
|
2fd33e9448 |
Extended-remote exec test
This patch updates several exec-related tests and some of the library functions in order to get them running with extended-remote. There were three changes that were required, as follows: In gdb.base/foll-exec.exp, use 'clean_start' in place of proc 'zap_session' to reset the state of the debugger between tests. This sets 'remote exec-file' to execute the correct binary file in each subsequent test. In gdb.base/pie-execl.exp, there is an expect statement with an expression that is used to match output from both gdb and the program under debug. For the remote target, this had to be split into two expressions, using $inferior_spawn_id to match the output from the program. Because I had encountered problems with extended-remote exec events in non-stop mode in my manual testing, I added non-stop testing to the non-ldr-exc-[1234].exp tests. In order to set non-stop mode for remote targets, it is necessary to 'set non-stop on' after gdb has started, but before it connects to gdbserver. This is done using 'save_vars' to set non-stop mode in GDBFLAGS, so GDB sets non-stop mode on startup. gdb/testsuite/ChangeLog: * gdb.base/foll-exec.c: Add copyright header. Fix formatting issues. * gdb.base/foll-exec.exp (zap_session): Delete proc. (do_exec_tests): Use clean_restart in place of zap_session, and for test initialization. Fix formatting issues. Use fail in place of perror. * gdb.base/pie-execl.exp (main): Use 'inferior_spawn_id' in an expect statement to match an expression with output from the program under debug. * gdb.threads/non-ldr-exc-1.exp (do_test, main): Add non-stop tests and pass stop mode argument to clean_restart. Use save_vars to enable non-stop in GDBFLAGS. * gdb.threads/non-ldr-exc-2.exp: Likewise. * gdb.threads/non-ldr-exc-3.exp: Likewise. * gdb.threads/non-ldr-exc-4.exp: Likewise. |
||
Sandra Loosemore
|
c0fa8fbd1c |
Improve hand-call-in-threads.exp failure handling.
2015-09-08 Sandra Loosemore <sandra@codesourcery.com> gdb/testsuite/ * gdb.threads/hand-call-in-threads.exp: Make sure the thread command actually switches threads. Give up on remaining tests if target fails to stop at breakpoint. |
||
Pedro Alves
|
d4569d7bc5 |
Fix step-over-{trips-on-watchpoint|lands-on-breakpoint}.exp race
On a target that is both always in non-stop mode and can do displaced stepping (such as native x86_64 GNU/Linux, with "maint set target-non-stop on"), the step-over-trips-on-watchpoint.exp test sometimes fails like this: (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: thread 1 set scheduler-locking off (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off step -[Switching to Thread 0x7ffff7fc0700 (LWP 11782)] -Hardware watchpoint 4: watch_me - -Old value = 0 -New value = 1 -child_function (arg=0x0) at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:39 -39 other = 1; /* set thread-specific breakpoint here */ -(gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step +wait_threads () at /home/pedro/gdb/mygit/src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49 +49 return 1; /* in wait_threads */ +(gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step Note "scheduler-locking" was set off. The problem is that on such targets, the step-over of thread 2 and the "step" of thread 1 can be set to run simultaneously (since with displaced stepping the breakpoint isn't ever removed from the target), and sometimes, the "step" of thread 1 finishes first, so it'd take another resume to see the watchpoint trigger. Fix this by replacing the wait_threads function with a one-line infinite loop that doesn't call any function, so that the "step" of thread 1 never finishes. gdb/testsuite/ChangeLog: 2015-08-07 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.c (wait_threads): Delete function. (main): Add alarm. Run an infinite loop instead of calling wait_threads. * gdb.threads/step-over-lands-on-breakpoint.exp (do_test): Change comment. * gdb.threads/step-over-trips-on-watchpoint.c (wait_threads): Delete function. (main): Add alarm. Run an infinite loop instead of calling wait_threads. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Change comment. |
||
Pedro Alves
|
d55007b583 |
Fix signal-while-stepping-over-bp-other-thread.exp on targets always in non-stop
With "maint set target-non-stop on" we get: -PASS: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: step +FAIL: gdb.threads/signal-while-stepping-over-bp-other-thread.exp: step The issue is simply that switch_back_to_stepped_thread is not used in non-stop mode, thus infrun doesn't output the expected "switching back to stepped thread" log. gdb/testsuite/ChangeLog: 2015-08-07 Pedro Alves <palves@redhat.com> * signal-while-stepping-over-bp-other-thread.exp: Expect "restart threads" as alternative to "switching back to stepped thread". |
||
Pedro Alves
|
f6a9d9c7db |
Revert "test slowdown"
That was pushed by mistake. |
||
Pedro Alves
|
83e97ed023 |
Test for PR18749: problems if whole process dies while (ptrace-) stopped
This adds a kfailed test that has the whole process exit just while several threads continuously step over a breakpoint. Usually, the process exits just while GDB or GDBserver is handling the breakpoint hit. In other words, the process disappears while the event thread is (ptrace-) stopped. This exposes several issues in GDB and GDBserver. Errors, crashes, etc. I fixed some of these issues recently, but there's a lot more to do. It's a bit like playing whack-a-mole at the moment. You fix an issue, which then exposes several others. E.g., with the native target, you get (among other errors): (...) [New Thread 0x7ffff47b9700 (LWP 18077)] [New Thread 0x7ffff3fb8700 (LWP 18078)] [New Thread 0x7ffff37b7700 (LWP 18079)] Cannot find user-level thread for LWP 18076: generic error (gdb) KFAIL: gdb.threads/process-dies-while-handling-bp.exp: non_stop=on: cond_bp_target=1: inferior 1 exited (prompt) (PRMS: gdb/18749) gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> PR gdb/18749 * gdb.threads/process-dies-while-handling-bp.c: New file. * gdb.threads/process-dies-while-handling-bp.exp: New file. |
||
Pedro Alves
|
4807d3f329 | test slowdown | ||
Pedro Alves
|
863d01bde2 |
gdbserver: Fix non-stop / fork / step-over issues
Ref: https://sourceware.org/ml/gdb-patches/2015-07/msg00868.html This adds a test that has a multithreaded program have several threads continuously fork, while another thread continuously steps over a breakpoint. This exposes several intertwined issues, which this patch addresses: - When we're stopping and suspending threads, some thread may fork, and we missed setting its suspend count to 1, like we do when a new clone/thread is detected. When we next unsuspend threads, the fork child's suspend count goes below 0, which is bogus and fails an assertion. - If a step-over is cancelled because a signal arrives, but then gdb is not interested in the signal, we pass the signal straight back to the inferior. However, we miss that we need to re-increment the suspend counts of all other threads that had been paused for the step-over. As a result, other threads indefinitely end up stuck stopped. - If a detach request comes in just while gdbserver is handling a step-over (in the test at hand, this is GDB detaching the fork child), gdbserver internal errors in stabilize_thread's helpers, which assert that all thread's suspend counts are 0 (otherwise we wouldn't be able to move threads out of the jump pads). The suspend counts aren't 0 while a step-over is in progress, because all threads but the one stepping past the breakpoint must remain paused until the step-over finishes and the breakpoint can be reinserted. - Occasionally, we see "BAD - reinserting but not stepping." being output (from within linux_resume_one_lwp_throw). That was because GDB pokes memory while gdbserver is busy with a step-over, and that suspends threads, and then re-resumes them with proceed_one_lwp, which missed another reason to tell linux_resume_one_lwp that the thread should be set back to stepping. - In a couple places, we were resuming threads that are meant to be suspended. E.g., when a vCont;c/s request for thread B comes in just while gdbserver is stepping thread A past a breakpoint. The resume for thread B must be deferred until the step-over finishes. - The test runs with both "set detach-on-fork" on and off. When off, it exercises the case of GDB detaching the fork child explicitly. When on, it exercises the case of gdb resuming the child explicitly. In the "off" case, gdb seems to exponentially become slower as new inferiors are created. This is _very_ noticeable as with only 100 inferiors gdb is crawling already, which makes the test take quite a bit to run. For that reason, I've disabled the "off" variant for now. gdb/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * target/waitstatus.h (enum target_stop_reason) <TARGET_STOPPED_BY_SINGLE_STEP>: New value. gdb/gdbserver/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the fork child's suspend count if stopping and suspending threads. (check_stopped_by_breakpoint): If stopped by trace, set the LWP's stop reason to TARGET_STOPPED_BY_SINGLE_STEP. (linux_detach): Complete an ongoing step-over. (lwp_suspended_inc, lwp_suspended_decr): New functions. Use throughout. (resume_stopped_resumed_lwps): Don't resume a suspended thread. (linux_wait_1): If passing a signal to the inferior after finishing a step-over, unsuspend and re-resume all lwps. If we see a single-step event but the thread should be continuing, don't pass the trap to gdb. (stuck_in_jump_pad_callback, move_out_of_jump_pad_callback): Use internal_error instead of gdb_assert. (enqueue_pending_signal): New function. (check_ptrace_stopped_lwp_gone): Add debug output. (start_step_over): Use internal_error instead of gdb_assert. (complete_ongoing_step_over): New function. (linux_resume_one_thread): Don't resume a suspended thread. (proceed_one_lwp): If the LWP is stepping over a breakpoint, reset it stepping. gdb/testsuite/ChangeLog: 2015-08-06 Pedro Alves <palves@redhat.com> * gdb.threads/forking-threads-plus-breakpoint.exp: New file. * gdb.threads/forking-threads-plus-breakpoint.c: New file. |
||
Pedro Alves
|
0a39bb3218 |
stepping is disturbed by setjmp/longjmp | try/catch in other threads
At https://sourceware.org/ml/gdb-patches/2015-08/msg00097.html, Joel observed that trying to next/step a program on GNU/Linux sometimes results in the following failed assertion: % gdb -q .obj/gprof/main (gdb) start (gdb) n (gdb) step [...]/infrun.c:2391: internal-error: resume: Assertion `sig != GDB_SIGNAL_0' failed. What happened is that, during the "next" operation, GDB hit a longjmp/exception/step-resume breakpoint but failed to see that this breakpoint was set for a different thread than the one being stepped. Joel's detailed analysis follows: More precisely, at the end of the "start" command, we are stopped at the start of function Main in main.adb; there are 4 threads in total, and we are in the main thread (which is thread 1): (gdb) info thread Id Target Id Frame 4 Thread 0xb7a56ba0 (LWP 28379) 0xffffe410 in __kernel_vsyscall () 3 Thread 0xb7c5aba0 (LWP 28378) 0xffffe410 in __kernel_vsyscall () 2 Thread 0xb7e5eba0 (LWP 28377) 0xffffe410 in __kernel_vsyscall () * 1 Thread 0xb7ea18c0 (LWP 28370) main () at /[...]/main.adb:57 All the logs below reference Thread ID/LWP, but it'll be easier to talk about the threads by GDB thread number. For instance, thread 1 is LWP 28370 while thread 3 is LWP 28378. So, the explanations below translate the LWPs into thread numbers. Back to what happens while we are trying to "next' our program: (gdb) n infrun: clear_proceed_status_thread (Thread 0xb7a56ba0 (LWP 28379)) infrun: clear_proceed_status_thread (Thread 0xb7c5aba0 (LWP 28378)) infrun: clear_proceed_status_thread (Thread 0xb7e5eba0 (LWP 28377)) infrun: clear_proceed_status_thread (Thread 0xb7ea18c0 (LWP 28370)) infrun: proceed (addr=0xffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x805451e infrun: target_wait (-1.0.0, status) = infrun: 28370.28370.0 [Thread 0xb7ea18c0 (LWP 28370)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x8054523 We've resumed thread 1 (LWP 28370), and received in return a signal that the same thread stopped slightly further. It's still in the range of instructions for the line of source we started the "next" from, as evidenced by the following trace... infrun: stepping inside range [0x805451e-0x8054531] ... and thus, we decide to continue stepping the same thread: infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523 infrun: prepare_to_wait That's when we get an event from a different thread (thread 3)... infrun: target_wait (-1.0.0, status) = infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x80782d0 infrun: context switch infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378) ... which we find to be at the address where we set a breakpoint on "the unwinder debug hook" (namely "_Unwind_DebugHook"). But GDB fails to notice that the breakpoint was inserted for thread 1 only, and so decides to handle it as... infrun: BPSTAT_WHAT_SET_LONGJMP_RESUME ... and inserts a breakpoint at the corresponding resume address, as evidenced by this the next log: infrun: exception resume at 80542a2 That breakpoint seems innocent right now, but will play a role fairly quickly. But for now, GDB has inserted the exception-resume breakpoint, and needs to single-step thread 3 past the breakpoint it just hit. Thus, it temporarily disables the exception breakpoint, and requests a step of that thread: infrun: skipping breakpoint: stepping past insn at: 0x80782d0 infrun: skipping breakpoint: stepping past insn at: 0x80782d0 infrun: skipping breakpoint: stepping past insn at: 0x80782d0 infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=1, current thread [Thread 0xb7c5aba0 (LWP 28378)] at 0x80782d0 infrun: prepare_to_wait We then get a notification, still from thread 3, that it's now past that breakpoint... infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x8078424 ... so we can resume what we were doing before, which is single-stepping thread 1 until we get to a new line of code: infrun: switching back to stepped thread infrun: Switching context from Thread 0xb7c5aba0 (LWP 28378) to Thread 0xb7ea18c0 (LWP 28370) infrun: expected thread still hasn't advanced infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0xb7ea18c0 (LWP 28370)] at 0x8054523 The "resume" log above shows that we're resuming thread 1 from where we left off (0x8054523). We get one more stop at 0x8054529, which is still inside our stepping range so we go again. That's when we get the following event, from thread 3: infrun: prepare_to_wait infrun: target_wait (-1.0.0, status) = infrun: 28370.28378.0 [Thread 0xb7c5aba0 (LWP 28378)], infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x80542a2 Now the stop_pc address is interesting, because it's the address of "exception resume" breakpoint... infrun: context switch infrun: Switching context from Thread 0xb7ea18c0 (LWP 28370) to Thread 0xb7c5aba0 (LWP 28378) infrun: BPSTAT_WHAT_CLEAR_LONGJMP_RESUME ... and since that location is at a different line of code, this is where it decides the "next" operation should stop: infrun: stop_waiting [Switching to Thread 0xb7c5aba0 (LWP 28378)] 0x080542a2 in inte_tache_rt.ttache_rt ( <_task>=0x80968ec <inte_tache_rt_inst.tache2>) at /[...]/inte_tache_rt.adb:54 54 end loop; However, what GDB should have noticed earlier that the exception breakpoint we hit was for a different thread, thus should have single-stepped that thread out of the breakpoint _without_ inserting the exception-return breakpoint, and then resumed the single-stepping of the initial thread (thread 1) until that thread stepped out of its stepping range. This is what this patch does, and after applying it, GDB now correctly stops on the next line of code. The patch adds a C++ test that exercises this, both for setjmp/longjmp and exception breakpoints. With an unpatched GDB it shows: (gdb) next [Switching to Thread 22445.22455] thread_try_catch (arg=0x0) at /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/next-other-thr-longjmp.c:59 59 catch (...) (gdb) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 1 next /home/pedro/gdb/mygit/build/../src/gdb/infrun.c:4865: internal-error: process_event_stop_test: Assertion `ecs->event_thread->control.exception_resume_breakpoint != NULL' fa iled. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/next-other-thr-longjmp.exp: next to line 2 (GDB internal error) Resyncing due to internal error. n Tested on x86_64-linux, no regressions. gdb/ChangeLog: 2015-08-05 Pedro Alves <palves@redhat.com> Joel Brobecker <brobecker@adacore.com> * breakpoint.c (bpstat_what) <bp_longjmp, bp_longjmp_call_dummy> <bp_exception, bp_longjmp_resume, bp_exception_resume>: Handle the case where BS->STOP is not set. gdb/testsuite/ChangeLog: 2015-08-05 Pedro Alves <palves@redhat.com> * gdb.threads/next-while-other-thread-longjmps.c: New file. * gdb.threads/next-while-other-thread-longjmps.exp: New file. |
||
Pedro Alves
|
2c8c5d375e |
testsuite: tcl exec& -> 'kill -9 $pid' is racy (attach-many-short-lived-thread.exp races and others)
The buildbots show that attach-many-short-lived-thread.exp is racy. But after staring at debug logs and playing with SystemTap scripts for a (long) while, I figured out that neither GDB, nor the kernel nor the test's program itself are at fault. The problem is simply that the testsuite machinery is currently subject to PID-reuse races. The attach-many-short-lived-threads.c test program just happens to be much more susceptible to trigger this race because threads and processes share the same number space on Linux, and the test spawns many many short lived threads in succession, thus enlarging the race window a lot. Part of the problem is that several tests spawn processes with "exec&" (in order to test the "attach" command) , and then at the end of the test, to make sure things are cleaned up, issue a 'remote_spawn "kill -p $testpid"'. Since with tcl's "exec&", tcl itself is responsible for reaping the process's exit status, when we go kill the process, testpid may have already exited _and_ its status may have (and often has) been reaped already. Thus it can happen that another process meanwhile reuses $testpid, and that "kill" command kills the wrong process... Frequently, that happens to be attach-many-short-lived-thread, but this explains other test's races as well. In the attach-many-short-lived-threads test, it sometimes manifests like this: (gdb) file /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads Reading symbols from /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads...done. (gdb) Loaded /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads into /home/pedro/gdb/mygit/build/gdb/testsuite/../../gdb/gdb attach 5940 Attaching to program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/attach-many-short-lived-threads, process 5940 warning: process 5940 is a zombie - the process has already terminated ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ptrace: Operation not permitted. (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: attach info threads No threads. (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: no new threads set breakpoint always-inserted on (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 1: set breakpoint always-inserted on Other times the process dies while the test is ongoing (the process is ptrace-stopped): (gdb) print again = 1 Cannot access memory at address 0x6020cc (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: reset timer in the inferior (Recall that on Linux, SIGKILL is not interceptable) And other times it dies just while we're detaching: $4 = 319 (gdb) PASS: gdb.threads/attach-many-short-lived-threads.exp: iter 2: print seconds_left detach Can't detach Thread 0x7fb13b7de700 (LWP 1842): No such process (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 2: detach GDB mishandles the latter (it should ignore ESRCH while detaching just like when continuing), but that's another story. The fix here is to change spawn_wait_for_attach to use Expect's 'spawn' command instead of Tcl's 'exec&' to spawn programs, because with spawn we control when to wait for/reap the process. That allows killing the process by PID without being subject to pid-reuse races, because even if the process is already dead, the kernel won't reuse the process's PID until the zombie is reaped. The other part of the problem lies in DejaGnu itself, unfortunately. I have occasionally seen tests (attach-many-short-lived-threads included, but not only that one) die with a random inexplicable SIGTERM too, and that too is caused by the same reason, except that in that case, the rogue SIGTERM is sent from this bit in DejaGnu's remote.exp: exec sh -c "exec > /dev/null 2>&1 && (kill -2 $pgid || kill -2 $pid) && sleep 5 && (kill $pgid || kill $pid) && sleep 5 && (kill -9 $pgid || kill -9 $pid) &" ... catch "wait -i $shell_id" Even if the program exits promptly, that whole cascade of kills carries on in the background, thus potentially killing the poor process that manages to reuse $pid... I sent a fix for that to the DejaGnu list: http://lists.gnu.org/archive/html/dejagnu/2015-07/msg00000.html With both patches in place, I haven't seen attach-many-short-lived-threads.exp fail again. Tested on x86_64 Fedora 20, native, gdbserver and extended-gdbserver. gdb/testsuite/ChangeLog: 2015-07-31 Pedro Alves <palves@redhat.com> * gdb.base/attach-pie-misread.exp: Rename $res to $test_spawn_id. Use spawn_id_get_pid. Wait for spawn id after eof. Use kill_wait_spawned_process instead of explicit "kill -9". * gdb.base/attach-pie-noexec.exp: Adjust to spawn_wait_for_attach returning a spawn id instead of a pid. Use spawn_id_get_pid and kill_wait_spawned_process. * gdb.base/attach-twice.exp: Likewise. * gdb.base/attach.exp: Likewise. (do_command_attach_tests): Use gdb_spawn_with_cmdline_opts and gdb_test_multiple. * gdb.base/solib-overlap.exp: Adjust to spawn_wait_for_attach returning a spawn id instead of a pid. Use spawn_id_get_pid and kill_wait_spawned_process. * gdb.base/valgrind-infcall.exp: Likewise. * gdb.multi/multi-attach.exp: Likewise. * gdb.python/py-prompt.exp: Likewise. * gdb.python/py-sync-interp.exp: Likewise. * gdb.server/ext-attach.exp: Likewise. * gdb.threads/attach-into-signal.exp (corefunc): Use spawn_wait_for_attach, spawn_id_get_pid and kill_wait_spawned_process. * gdb.threads/attach-many-short-lived-threads.exp: Adjust to spawn_wait_for_attach returning a spawn id instead of a pid. Use spawn_id_get_pid and kill_wait_spawned_process. * gdb.threads/attach-stopped.exp (corefunc): Use spawn_wait_for_attach, spawn_id_get_pid and kill_wait_spawned_process. * gdb.base/break-interp.exp: Rename $res to $test_spawn_id. Use spawn_id_get_pid. Wait for spawn id after eof. Use kill_wait_spawned_process instead of explicit "kill -9". * lib/gdb.exp (can_spawn_for_attach): Adjust comment. (kill_wait_spawned_process, spawn_id_get_pid): New procedures. (spawn_wait_for_attach): Use spawn instead of exec to spawn processes. Don't map cygwin/windows pids here. Now returns a spawn id list. |
||
Pedro Alves
|
998d452ac8 |
remote follow fork and spurious child stops in non-stop mode
Running gdb.threads/fork-plus-threads.exp against gdbserver in extended-remote mode, even though the test passes, we still see broken behavior: (gdb) PASS: gdb.threads/fork-plus-threads.exp: set detach-on-fork off continue & Continuing. (gdb) PASS: gdb.threads/fork-plus-threads.exp: continue & [New Thread 28092.28092] [Thread 28092.28092] #2 stopped. [New Thread 28094.28094] [Inferior 2 (process 28092) exited normally] [New Thread 28094.28105] [New Thread 28094.28109] ... [Thread 28174.28174] #18 stopped. [New Thread 28185.28185] [Inferior 10 (process 28174) exited normally] [New Thread 28185.28196] [Thread 28185.28185] #20 stopped. Cannot remove breakpoints because program is no longer writable. Further execution is probably impossible. [Inferior 11 (process 28185) exited normally] [Inferior 1 (process 28091) exited normally] PASS: gdb.threads/fork-plus-threads.exp: reached breakpoint info threads No threads. (gdb) PASS: gdb.threads/fork-plus-threads.exp: no threads left info inferiors Num Description Executable * 1 <null> /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/fork-plus-threads (gdb) PASS: gdb.threads/fork-plus-threads.exp: only inferior 1 left All the "[Thread FOO] #NN stopped." above are bogus, as well as the "Cannot remove breakpoints because program is no longer writable.", which is a consequence. The problem is that when we intercept a fork event, we should report the event for the parent, only, and leave the child stopped, but not report its stop event. GDB later decides whether to follow the parent or the child. But because handle_extended_wait does not set the child's last_status.kind to TARGET_WAITKIND_STOPPED, a stop_all_threads/unstop_all_lwps sequence (e.g., from trying to access memory) by mistake ends up queueing a SIGSTOP on the child, resuming it, and then when that SIGSTOP is intercepted, because the LWP has last_resume_kind set to resume_stop, gdbserver reports the stop to GDB, as GDB_SIGNAL_0: ... >>>> entering unstop_all_lwps unstopping all lwps proceed_one_lwp: lwp 1600 client wants LWP to remain 1600 stopped proceed_one_lwp: lwp 1828 Client wants LWP 1828 to stop. Making sure it has a SIGSTOP pending ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sending sigstop to lwp 1828 pc is 0x3615ebc7cc Resuming lwp 1828 (continue, signal 0, stop expected) continue from pc 0x3615ebc7cc unstop_all_lwps done sigchld_handler <<<< exiting unstop_all_lwps handling possible target event >>>> entering linux_wait_1 linux_wait_1: [<all threads>] my_waitpid (-1, 0x40000001) my_waitpid (-1, 0x1): status(137f), 1828 LWFE: waitpid(-1, ...) returned 1828, ERRNO-OK LLW: waitpid 1828 received Stopped (signal) (stopped) pc is 0x3615ebc7cc Expected stop. LLW: resume_stop SIGSTOP caught for LWP 1828.1828. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... linux_wait_1 ret = LWP 1828.1828, 1, 0 <<<< exiting linux_wait_1 Writing resume reply for LWP 1828.1828:1 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Tested on x86_64 Fedora 20, extended-remote. gdb/gdbserver/ChangeLog: 2015-07-30 Pedro Alves <palves@redhat.com> * linux-low.c (handle_extended_wait): Set the child's last reported status to TARGET_WAITKIND_STOPPED. |
||
Pedro Alves
|
69dde7dcb8 |
PR threads/18600: Inferiors left around after fork+thread spawn
The new gdb.threads/fork-plus-threads.exp test exposes one more problem. When one types "info inferiors" after running the program, one see's a couple inferior left still, while there should only be inferior #1 left. E.g.: (gdb) info inferiors Num Description Executable 4 process 8393 /home/pedro/bugs/src/test 2 process 8388 /home/pedro/bugs/src/test * 1 <null> /home/pedro/bugs/src/test (gdb) info threads Calling prune_inferiors() manually at this point (from a top gdb) does not remove them, because they still have inf->pid != 0 (while they shouldn't). This suggests that we never mourned those inferiors. Enabling logs (master + previous patch) we see: ... WL: waitpid Thread 0x7ffff7fc2740 (LWP 9513) received Trace/breakpoint trap (stopped) WL: Handling extended status 0x03057f LHEW: Got clone event from LWP 9513, new child is LWP 9579 [New Thread 0x7ffff37b8700 (LWP 9579)] WL: waitpid Thread 0x7ffff7fc2740 (LWP 9508) received 0 (exited) WL: Thread 0x7ffff7fc2740 (LWP 9508) exited. ^^^^^^^^ [Thread 0x7ffff7fc2740 (LWP 9508) exited] WL: waitpid Thread 0x7ffff7fc2740 (LWP 9499) received 0 (exited) WL: Thread 0x7ffff7fc2740 (LWP 9499) exited. [Thread 0x7ffff7fc2740 (LWP 9499) exited] RSRL: resuming stopped-resumed LWP Thread 0x7ffff37b8700 (LWP 9579) at 0x3615ef4ce1: step=0 ... (gdb) info inferiors Num Description Executable 5 process 9508 /home/pedro/bugs/src/test ^^^^ 4 process 9503 /home/pedro/bugs/src/test 3 process 9500 /home/pedro/bugs/src/test 2 process 9499 /home/pedro/bugs/src/test * 1 <null> /home/pedro/bugs/src/test (gdb) ... Note the "Thread 0x7ffff7fc2740 (LWP 9508) exited." line. That's this in wait_lwp: /* Check if the thread has exited. */ if (WIFEXITED (status) || WIFSIGNALED (status)) { thread_dead = 1; if (debug_linux_nat) fprintf_unfiltered (gdb_stdlog, "WL: %s exited.\n", target_pid_to_str (lp->ptid)); } } That was the leader thread reporting an exit, meaning the whole process is gone. So the problem is that this code doesn't understand that an WIFEXITED status of the leader LWP should be reported to infrun as process exit. gdb/ChangeLog: 2015-07-30 Pedro Alves <palves@redhat.com> PR threads/18600 * linux-nat.c (wait_lwp): Report to the core when thread group leader exits. gdb/testsuite/ChangeLog: 2015-07-30 Pedro Alves <palves@redhat.com> PR threads/18600 * gdb.threads/fork-plus-threads.exp: Test that "info inferiors" only shows inferior 1. |
||
Pedro Alves
|
4dd63d488a |
PR threads/18600: Threads left stopped after fork+thread spawn
When a program forks and another process start threads while gdb is handling the fork event, newly created threads are left stuck stopped by gdb, even though gdb presents them as "running", to the user. This can be seen with the test added by this patch. The test has the inferior fork a certain number of times and waits for all children to exit. Each fork child spawns a number of threads that do nothing and joins them immediately. Normally, the program should run unimpeded (from the point of view of the user) and exit very quickly. Without this fix, it doesn't because of some threads left stopped by gdb, so inferior 1 never exits. The program triggers when a new clone thread is found while inside the linux_stop_and_wait_all_lwps call in linux-thread-db.c: linux_stop_and_wait_all_lwps (); ALL_LWPS (lp) if (ptid_get_pid (lp->ptid) == pid) thread_from_lwp (lp->ptid); linux_unstop_all_lwps (); Within linux_stop_and_wait_all_lwps, we reach linux_handle_extended_wait with the "stopping" parameter set to 1, and because of that we don't mark the new lwp as resumed. As consequence, the subsequent resume_stopped_resumed_lwps, called from linux_unstop_all_lwps, never resumes the new LWP. There's lots of cruft in linux_handle_extended_wait that no longer makes sense. On systems with CLONE events support, we don't rely on libthread_db for thread listing anymore, so the code that preserves stop_requested and the handling of last_resume_kind is all dead. So the fix is to remove all that, and simply always mark the new LWP as resumed, so that resume_stopped_resumed_lwps re-resumes it. gdb/ChangeLog: 2015-07-30 Pedro Alves <palves@redhat.com> Simon Marchi <simon.marchi@ericsson.com> PR threads/18600 * linux-nat.c (linux_handle_extended_wait): On CLONE event, always mark the new thread as resumed. Remove STOPPING parameter. (wait_lwp): Adjust call to linux_handle_extended_wait. (linux_nat_filter_event): Adjust call to linux_handle_extended_wait. (resume_stopped_resumed_lwps): Add debug output. gdb/testsuite/ChangeLog: 2015-07-30 Simon Marchi <simon.marchi@ericsson.com> Pedro Alves <palves@redhat.com> PR threads/18600 * gdb.threads/fork-plus-threads.c: New file. * gdb.threads/fork-plus-threads.exp: New file. |
||
Sergio Durigan Junior
|
7da5b897c9 |
Uniquefy gdb.threads/attach-into-signal.exp
Hi, While examining BuildBot's logs, I noticed: <https://sourceware.org/ml/gdb-testers/2015-q3/msg03767.html> gdb.threads/attach-into-signal.exp has two nested loops and don't use unique messages. This commit fixes that. Pushed under the obvious rule. gdb/testsuite/ChangeLog: 2015-07-29 Sergio Durigan Junior <sergiodj@redhat.com> * gdb.threads/attach-into-signal.exp (corefunc): Use with_test_prefix on nested loops, uniquefying the test messages. |
||
Pedro Alves
|
7759842763 |
PR gdb/18717: internal error if non-leader thread exits process
If a non-leader thread exits the process while all other threads are ptrace-stopped, native gdb fails an assertion. The test added by this commit catches it: /home/pedro/gdb/mygit/build/../src/gdb/linux-nat.c:3198: internal-error: linux_nat_filter_event: Assertion `lp->resumed' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) FAIL: gdb.threads/non-leader-exit-process.exp: program exits normally (GDB internal error) The fix is just to remove the assertion. With that out of the way, neither GDB not GDBserver handle this perfectly though, so I'm adding a KFAIL: (gdb) continue Continuing. [Thread 0x7ffff7fc0700 (LWP 15350) exited] No unwaited-for children left. Couldn't get registers: No such process. (gdb) KFAIL: gdb.threads/non-ldr-exit.exp: program exits normally (PRMS: gdb/18717) gdb/ChangeLog: 2015-07-24 Pedro Alves <palves@redhat.com> PR gdb/18717 * linux-nat.c (linux_nat_filter_event): Don't assert that the lwp is resumed, and extend the debug log. gdb/testsuite/ChangeLog: 2015-07-24 Pedro Alves <palves@redhat.com> PR gdb/18717 * gdb.threads/non-ldr-exit.c: New file. * gdb.threads/non-ldr-exit.exp: New file. |
||
Pedro Alves
|
28bf096c62 |
PR threads/18127 - threads spawned by infcall end up stuck in "running" state
Refs: https://sourceware.org/ml/gdb/2015-03/msg00024.html https://sourceware.org/ml/gdb/2015-06/msg00005.html On GNU/Linux, if an infcall spawns a thread, that thread ends up with stuck running state. This happens because: - when linux-nat.c detects a new thread, it marks them as running, and does not report anything to the core. - we skip finish_thread_state when the thread that is running the infcall stops. As result, that new thread ends up with stuck "running" state, even though it really is stopped. On Windows, _all_ threads end up stuck in running state, not just the one that was spawned. That happens because when a new thread is detected, unlike linux-nat.c, windows-nat.c reports TARGET_WAITKIND_SPURIOUS to infrun. It's the fact that that event does not cause a user-visible stop that triggers the problem. When the target is re-resumed, we call set_running with a wildcard ptid, which marks all thread as running. That set_running is not suppressed because the (leader) thread being resumed does not have in_infcall set. Later, when the infcall finally finishes successfully, nothing marks all threads back to stopped. We can trigger the same problem on all targets by having a thread other than the one that is running the infcall report a breakpoint hit to infrun, and then have that breakpoint not cause a stop. That's what the included test does. The fix is to stop GDB from suppressing the set_running calls while doing an infcall, and then set the threads back to stopped when the call finishes, iff they were originally stopped before the infcall started. (Note the MI *running/*stopped event suppression isn't affected.) Tested on x86_64 GNU/Linux. gdb/ChangeLog: 2015-06-29 Pedro Alves <palves@redhat.com> PR threads/18127 * infcall.c (run_inferior_call): On infcall success, if the thread was marked stopped before, reset it back to stopped. * infrun.c (resume): Don't suppress the set_running calls when doing an infcall. (normal_stop): Only discard the finish_thread_state cleanup if the infcall succeeded. gdb/testsuite/ChangeLog: 2015-06-29 Pedro Alves <palves@redhat.com> PR threads/18127 * gdb.threads/hand-call-new-thread.c: New file. * gdb.threads/hand-call-new-thread.c: New file. |
||
Pedro Alves
|
9ee417720b |
Cleanup signal-while-stepping-over-bp-other-thread.exp
gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/signal-while-stepping-over-bp-other-thread.exp: Use gdb_test_sequence and gdb_assert. |
||
Pedro Alves
|
07473109e1 |
step-over-trips-on-watchpoint.exp: Don't put addresses in test messages
Diffing test results, I noticed: -PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x0000000000400811 thread 1 +PASS: gdb.threads/step-over-trips-on-watchpoint.exp: displaced=on: with thread-specific bp: next: b *0x00000000004007d1 thread 1 gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Use test messages that don't include the breakpoint address. |
||
Pedro Alves
|
c79d856c88 |
Test step-over-{lands-on-breakpoint|trips-on-watchpoint}.exp with displaced stepping
These tests exercise the infrun.c:proceed code that needs to know to start new step overs (along with switch_back_to_stepped_thread, etc.). That code is tricky to get right in the multitude of possible combinations (at least): (native | remote) X (all-stop | all-stop-but-target-always-in-non-stop) X (displaced-stepping | in-line step-over). The first two above are properties of the target, but the different step-over-breakpoint methods should work with any target that supports them. This patch makes sure we always test both methods on all targets. Tested on x86-64 Fedora 20. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-lands-on-breakpoint.exp (do_test): New procedure, factored out from ... (top level): ... here. Add "set displaced-stepping" testing axis. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): New parameter "displaced". Use it. (top level): Use foreach and add "set displaced-stepping" testing axis. |
||
Pedro Alves
|
ebc90b50ce |
Make gdb.threads/step-over-trips-on-watchpoint.exp effective on !x86
This test is currently failing like this on (at least) PPC64 and s390x: FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: next: next FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: step: step FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: with thread-specific bp: next: next gdb.log: (gdb) PASS: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: set scheduler-locking off step wait_threads () at ../../../src/gdb/testsuite/gdb.threads/step-over-trips-on-watchpoint.c:49 49 return 1; /* in wait_threads */ (gdb) FAIL: gdb.threads/step-over-trips-on-watchpoint.exp: no thread-specific bp: step: step The problem is that the test assumes that both the "watch_me = 1;" and the "other = 1;" lines compile to a single instruction each, which happens to be true on x86, but no necessarily true everywhere else. The result is that the test doesn't really test what it wants to test. Fix it by looking for the instruction that triggers the watchpoint. gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> * gdb.threads/step-over-trips-on-watchpoint.c (child_function): Remove comment. * gdb.threads/step-over-trips-on-watchpoint.exp (do_test): Find both the address of the instruction that triggers the watchpoint and the address of the instruction immediately after, and use those addresses for the test. Fix comment. |
||
Pedro Alves
|
8d707a12ef |
gdb/18216: displaced step+deliver signal, a thread needs step-over, crash
The problem is that with hardware step targets and displaced stepping, "signal FOO" when stopped at a breakpoint steps the breakpoint instruction at the same time it delivers a signal. This results in tp->stepped_breakpoint set, but no step-resume breakpoint set. When the next stop event arrives, GDB crashes. Irrespective of whether we should do something more/different to step past the breakpoint in this scenario (e.g., PR 18225), it's just wrong to assume there'll be a step-resume breakpoint set (and was not the original intention). gdb/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * infrun.c (process_event_stop_test): Don't assume a step-resume is set if tp->stepped_breakpoint is true. gdb/testsuite/ChangeLog: 2015-04-10 Pedro Alves <palves@redhat.com> PR gdb/18216 * gdb.threads/multiple-step-overs.exp: Remove expected eof. |
||
Pedro Alves
|
f3770638ca |
Add test for PR18214 and PR18216 - multiple step-overs with queued signals
Both PRs are triggered by the same use case. PR18214 is about software single-step targets. On those, the 'resume' code that detects that we're stepping over a breakpoint and delivering a signal at the same time: /* Currently, our software single-step implementation leads to different results than hardware single-stepping in one situation: when stepping into delivering a signal which has an associated signal handler, hardware single-step will stop at the first instruction of the handler, while software single-step will simply skip execution of the handler. ... Fortunately, we can at least fix this particular issue. We detect here the case where we are about to deliver a signal while software single-stepping with breakpoints removed. In this situation, we revert the decisions to remove all breakpoints and insert single- step breakpoints, and instead we install a step-resume breakpoint at the current address, deliver the signal without stepping, and once we arrive back at the step-resume breakpoint, actually step over the breakpoint we originally wanted to step over. */ doesn't handle the case of _another_ thread also needing to step over a breakpoint. Because the other thread is just resumed at the PC where it had stopped and a breakpoint is still inserted there, the thread immediately re-traps the same breakpoint. This test exercises that. On software single-step targets, it fails like this: KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr2: continue to sigusr1_handler gdb.log (simplified): (gdb) continue Continuing. Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66 66 callme (); /* set breakpoint thread 2 here */ (gdb) thread 3 (gdb) queue-signal SIGUSR1 (gdb) thread 1 [Switching to thread 1 (Thread 0x7ffff7fc1740 (LWP 24824))] #0 main () at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:106 106 wait_threads (); /* set wait-threads breakpoint here */ (gdb) break sigusr1_handler Breakpoint 5 at 0x400837: file src/gdb/testsuite/gdb.threads/multiple-step-overs.c, line 31. (gdb) continue Continuing. [Switching to Thread 0x7ffff7fc0700 (LWP 24828)] Breakpoint 4, child_function_2 (arg=0x0) at src/gdb/testsuite/gdb.threads/multiple-step-overs.c:66 66 callme (); /* set breakpoint thread 2 here */ (gdb) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=off: signal thr3: continue to sigusr1_handler For good measure, I made the test try displaced stepping too. And then I found it crashes GDB on x86-64 (a hardware step target), but only when displaced stepping... : KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr1: continue to sigusr1_handler (PRMS: gdb/18216) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr2: continue to sigusr1_handler (PRMS: gdb/18216) KFAIL: gdb.threads/multiple-step-overs.exp: displaced=on: signal thr3: continue to sigusr1_handler (PRMS: gdb/18216) Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964 4964 if (sr_bp->loc->permanent Setting up the environment for debugging gdb. Breakpoint 1 at 0x79fcfc: file src/gdb/common/errors.c, line 54. Breakpoint 2 at 0x50a26c: file src/gdb/cli/cli-cmds.c, line 217. (top-gdb) p sr_bp $1 = (struct breakpoint *) 0x0 (top-gdb) bt #0 0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964 #1 0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4715 #2 0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4165 #3 0x0000000000627482 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3298 #4 0x000000000064ad7b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56 #5 0x00000000004c375f in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4658 #6 0x0000000000648c47 in handle_file_event (file_ptr=0x2e0eaa0, ready_mask=1) at src/gdb/event-loop.c:658 The all-stop-non-stop series fixes this, but meanwhile, this augments the multiple-step-overs.exp test to cover this, KFAILed. gdb/testsuite/ChangeLog: 2015-04-08 Pedro Alves <palves@redhat.com> PR gdb/18214 PR gdb/18216 * gdb.threads/multiple-step-overs.c (sigusr1_handler): New function. (main): Install it as SIGUSR1 handler. * gdb.threads/multiple-step-overs.exp (setup): Remove 'prefix' parameter. Always use "setup" as prefix. Toggle "set displaced-stepping" off/on depending on global. Don't switch to thread 1 here. (top level): Add displaced stepping "off/on" test axis. Update "setup" calls. Wrap each subtest with with_test_prefix. Test continuing with a queued signal in each thread. |
||
Yao Qi
|
337532fab1 |
Properly set alarm value in gdb.threads/non-stop-fair-events.exp
Nowadays, the alarm value is 60, and alarm is generated on some slow boards. This patch is to pass DejaGNU timeout value to the program, and move the alarm call before going to infinite loop. If any thread has activities, the alarm is reset. gdb/testsuite: 2015-04-07 Yao Qi <yao.qi@linaro.org> * gdb.threads/non-stop-fair-events.c (SECONDS): New macro. (child_function): Call alarm. (main): Move call to alarm into the loop. * gdb.threads/non-stop-fair-events.exp: Build program with -DTIMEOUT=$timeout. |
||
Yao Qi
|
cafda5977a |
kfail two tests in no-unwaited-for-left.exp for remote target
I see these two fails in no-unwaited-for-left.exp in remote testing for aarch64-linux target. ... continue Continuing. warning: Remote failure reply: E.No unwaited-for children left. [Thread 1084] #2 stopped. (gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when thread 2 exits .... continue Continuing. warning: Remote failure reply: E.No unwaited-for children left. [Thread 1081] #1 stopped. (gdb) FAIL: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits I checked the gdb.log on buildbot, and find that these two fails also appear on Debian-i686-native-extended-gdbserver and Fedora-ppc64be-native-gdbserver-m64. I recall that they are about local/remote parity, and related RSP is missing. There has been already a PR 14618 about it. This patch is to kfail them on remote target. gdb/testsuite: 2015-04-02 Yao Qi <yao.qi@linaro.org> * gdb.threads/no-unwaited-for-left.exp: Set up kfail if target is remote. |
||
Pedro Alves
|
a14711808e |
gdb.threads/manythreads.exp: can't read "test": no such variable
If interrupt_and_wait manages to trigger the FAIL path, we get: ERROR OCCURED: can't read "test": no such variable gdb/testsuite/ChangeLog: 2015-04-01 Pedro Alves <palves@redhat.com> * gdb.threads/manythreads.exp (interrupt_and_wait): Pass $message to fail instead of non-existent $test. |