Commit graph

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.
2016-03-16 15:13:44 -07:00
Pedro Alves
00dbd492e4 More "Program" -> "Thread NN received signal" testsuite adjustment
These tests should have been adjusted by f303dbd60d (Fix PR
threads/19422 - show which thread caused stop), but clearly I had
missed grepping for potential-fail cases.

gdb/testsuite/ChangeLog
2016-03-09  Pedro Alves  <palves@redhat.com>

	* gdb.threads/attach-into-signal.exp: Adjust to "Program received
	signal" -> "Thread NN received signal" output change.
	* gdb.threads/ia64-sigill.exp: Likewise.
	* gdb.threads/linux-dp.exp: Likewise.
	* gdb.threads/manythreads.exp: Likewise.
	* gdb.threads/pending-step.exp: Likewise.
	* gdb.threads/print-threads.exp: Likewise.
	* gdb.threads/sigstep-threads.exp: Likewise.
	* gdb.threads/staticthreads.exp: Likewise.
	* gdb.threads/tls.exp: Likewise.
2016-03-09 20:24:14 +00:00
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.
2016-03-01 17:25:56 +00:00
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.
2016-02-18 12:04:32 +00:00
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.
2016-02-16 08:56:06 -08:00
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.
2016-02-08 14:02:36 -05:00
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.
2016-02-01 18:48:04 +00:00
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.
2016-01-25 13:15:11 +00:00
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)]
    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.
2016-01-18 15:15:18 +00:00
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.
2016-01-13 11:03:19 +00:00
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.
2016-01-13 10:59:43 +00:00
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.
2016-01-12 01:12:38 +00:00
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.
2016-01-11 22:12:16 +01:00
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.
2016-01-01 08:43:22 +04:00
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.
2015-12-21 12:51:54 -05:00
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.
2015-12-14 15:02:59 -08:00
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.
2015-12-14 11:18:05 -08:00
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.
2015-11-30 18:43:24 +00:00
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.
2015-11-26 13:09:30 -05:00
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.
2015-11-24 18:36:31 +00:00
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.
2015-10-30 15:54:58 +00:00
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.
2015-09-16 15:51:36 +01:00
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.
2015-09-16 15:51:36 +01:00
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.
2015-09-15 21:12:39 +02:00
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 2fd33e9448.  This reverts the
hunk that introduced the problem, reverting back to
gdb_continue_to_breakpoint.

gdb/testsuite/ChangeLog:
2015-09-15  Pedro Alves  <palves@redhat.com>

	* gdb.threads/non-ldr-exc-3.exp (do_test): Use
	gdb_continue_to_breakpoint instead of gdb_test_multiple.
2015-09-15 17:01:59 +01:00
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.
2015-09-11 11:12:46 -07:00
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.
2015-09-08 19:49:04 -07:00
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.
2015-08-07 17:26:21 +01:00
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".
2015-08-07 17:26:20 +01:00
Pedro Alves
f6a9d9c7db Revert "test slowdown"
That was pushed by mistake.
2015-08-06 12:45:45 +01:00
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.
2015-08-06 12:33:20 +01:00
Pedro Alves
4807d3f329 test slowdown 2015-08-06 12:33:19 +01:00
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.
2015-08-06 10:30:18 +01:00
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.
2015-08-05 20:01:42 +01:00
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.
2015-07-31 20:06:24 +01:00
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]  stopped.
 [New Thread 28094.28094]
 [Inferior 2 (process 28092) exited normally]
 [New Thread 28094.28105]
 [New Thread 28094.28109]

...

[Thread 28174.28174]  stopped.
 [New Thread 28185.28185]
 [Inferior 10 (process 28174) exited normally]
 [New Thread 28185.28196]

 [Thread 28185.28185]  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.
2015-07-30 18:52:53 +01:00
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  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.
2015-07-30 18:52:09 +01:00
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.
2015-07-30 18:50:29 +01:00
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.
2015-07-29 11:10:49 -04:00
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.
2015-07-24 17:49:17 +01:00
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.
2015-06-29 16:07:57 +01:00
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.
2015-04-10 19:49:00 +01:00
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.
2015-04-10 19:23:24 +01:00
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.
2015-04-10 13:31:59 +01:00
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.
2015-04-10 13:11:32 +01:00
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.
2015-04-10 10:36:23 +01:00
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))]
   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.
   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
   0x000000000062a83a in process_event_stop_test (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4964
   0x000000000062a1af in handle_signal_stop (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4715
   0x0000000000629097 in handle_inferior_event (ecs=0x7fff847eeee0) at src/gdb/infrun.c:4165
   0x0000000000627482 in fetch_inferior_event (client_data=0x0) at src/gdb/infrun.c:3298
   0x000000000064ad7b in inferior_event_handler (event_type=INF_REG_EVENT, client_data=0x0) at src/gdb/inf-loop.c:56
   0x00000000004c375f in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4658
   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.
2015-04-08 19:59:03 +01:00
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.
2015-04-07 11:30:07 +01:00
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]  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]  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.
2015-04-02 13:51:31 +01:00
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.
2015-04-01 15:30:13 +01:00