Say:
<stopped at a breakpoint in thread 2>
(gdb) thread 3
(gdb) step
The above triggers the prepare_to_proceed/deferred_step_ptid process,
which switches back to thread 2, to step over its breakpoint before
getting back to thread 3 and "step" it.
If while stepping over the breakpoint in thread 2, a signal arrives,
and it is set to pass/nostop, we'll set a step-resume breakpoint at
the supposed signal-handler resume address, and call keep_going. The
problem is that we were supposedly stepping thread 3, and that
keep_going delivers a signal to thread 2, and due to scheduler-locking
off, resumes everything else, _including_ thread 3, the thread we want
stepping. This means that we lose control of thread 3 until the next
event, when we stop everything. The end result for the user, is that
GDB lost control of the "step".
Here's the current infrun debug output of the above, with the testcase
in the patch below:
infrun: clear_proceed_status_thread (Thread 0x2aaaab8f5700 (LWP 11663))
infrun: clear_proceed_status_thread (Thread 0x2aaaab6f4700 (LWP 11662))
infrun: clear_proceed_status_thread (Thread 0x2aaaab4f2b20 (LWP 11659))
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: prepare_to_proceed (step=1), switched to [Thread 0x2aaaab6f4700 (LWP 11662)]
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGUSR1
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: random signal 30
Program received signal SIGUSR1, User defined signal 1.
infrun: signal arrived while stepping over breakpoint
infrun: inserting step-resume breakpoint at 0x40098f
infrun: resume (step=0, signal=30), trap_expected=0, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ this is a wildcard resume.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40098f
infrun: BPSTAT_WHAT_STEP_RESUME
infrun: resume (step=1, signal=0), trap_expected=1, current thread [Thread 0x2aaaab6f4700 (LWP 11662)] at 0x40098f
^^^ step-resume hit, meaning the handler returned, so we go back to stepping thread 3.
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab6f4700 (LWP 11662)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40088b
infrun: switching back to stepped thread
infrun: Switching context from Thread 0x2aaaab6f4700 (LWP 11662) to Thread 0x2aaaab8f5700 (LWP 11663)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x400938
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40093a
infrun: keep going
infrun: resume (step=1, signal=0), trap_expected=0, current thread [Thread 0x2aaaab8f5700 (LWP 11663)] at 0x40093a
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 11659 [Thread 0x2aaaab8f5700 (LWP 11663)],
infrun: status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x40091e
infrun: stepped to a different line
infrun: stop_stepping
[Switching to Thread 0x2aaaab8f5700 (LWP 11663)]
69 (*myp) ++; /* set breakpoint child_two here */
^^^ we stopped at the wrong line. We still stepped a bit because the
test is running in a loop, and when we got back to stepping thread 3,
it happened to be in the stepping range. (The loop increments a
counter, and the test makes sure it increments exactly once. Without
the fix, the counter increments a bunch, since the user-stepped thread
runs free without GDB noticing.)
The fix is to switch to the stepping thread before continuing for the
step-resume breakpoint.
gdb/
2014-02-07 Pedro Alves <palves@redhat.com>
* infrun.c (handle_signal_stop) <signal arrives while stepping
over a breakpoint>: Switch back to the stepping thread.
gdb/testsuite/
2014-02-07 Pedro Alves <pedro@codesourcery.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/step-after-sr-lock.c: New file.
* gdb.threads/step-after-sr-lock.exp: New file.
Currently on software single-step Linux targets we get:
(gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc"
stepi
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 7073))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 7069))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 7069)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 7069 [Thread 0x7ffff7fcb740 (LWP 7069)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: software single step trap for Thread 0x7ffff7fcb740 (LWP 7069)
infrun: stepi/nexti
infrun: stop_stepping
44 while (counter != 0)
(gdb) FAIL: gdb.threads/stepi-random-signal.exp: stepi (no random signal)
Vs hardware-step targets:
(gdb) PASS: gdb.threads/stepi-random-signal.exp: before stepi: get hexadecimal valueof "$pc"
stepi
infrun: clear_proceed_status_thread (Thread 0x7ffff7fca700 (LWP 9565))
infrun: clear_proceed_status_thread (Thread 0x7ffff7fcb740 (LWP 9561))
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT, step=1)
infrun: resume (step=1, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700
infrun: wait_for_inferior ()
infrun: target_wait (-1, status) =
infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_CHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400700
infrun: random signal (GDB_SIGNAL_CHLD)
infrun: random signal, keep going
infrun: resume (step=1, signal=GDB_SIGNAL_CHLD), trap_expected=0, current thread [Thread 0x7ffff7fcb740 (LWP 9561)] at 0x400700
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun: 9561 [Thread 0x7ffff7fcb740 (LWP 9561)],
infrun: status->kind = stopped, signal = GDB_SIGNAL_TRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400704
infrun: stepi/nexti
infrun: stop_stepping
44 while (counter != 0)
(gdb) PASS: gdb.threads/stepi-random-signal.exp: stepi
The test turns on infrun debug, does a stepi while a SIGCHLD is
pending, and checks whether the "random signal" paths in infrun.c are
taken.
On the software single-step variant above, those paths were not taken.
This is a test bug.
The Linux backend short-circuits reporting signals that are set to
pass/nostop/noprint. But _only_ if the thread is _not_
single-stepping. So on hardware-step targets, even though the signal
is set to pass/nostop/noprint by default, the thread is indeed told to
single-step, and so the core sees the signal. On the other hand, on
software single-step architectures, the backend never actually gets a
single-step request (steps are emulated by setting a breakpoint at the
next pc, and then the target told to continue, not step). So the
short-circuiting code triggers and the core doesn't see the signal.
The fix is to make the test be sure the target doesn't bypass
reporting the signal to the core.
Tested on x86_64 Fedora 17, both with and without a series that
implements software single-step for x86_64.
gdb/testsuite/
2014-02-07 Pedro Alves <palves@redhat.com>
* gdb.threads/stepi-random-signal.exp: Set SIGCHLD to print.
Currently, when GDB connects in all-stop mode, GDBserver always
responds to the status packet with a GDB_SIGNAL_TRAP, even if the
program is actually stopped for some other signal.
(gdb) tar rem ...
...
(gdb) c
Program received signal SIGUSR1, User defined signal 1.
(gdb) disconnect
(gdb) tar rem ...
(gdb) c
(Or a GDB crash instead of an explicit disconnect.)
This results in the program losing that signal on that last continue,
because gdb will tell the target to resume with no signal (to suppress
the GDB_SIGNAL_TRAP, due to 'handle SISGTRAP nopass'), and that will
actually suppress the real signal the program had stopped for
(SIGUSR1). To fix that, I think we should make GDBserver report the
real signal the thread had stopped for in response to the status
packet:
@item ?
@cindex @samp{?} packet
Indicate the reason the target halted. The reply is the same as for
step and continue.
But, that raises the question -- which thread are we reporting the
status for? Due to how the RSP in all-stop works, we can only report
one status. The status packet's response is a stop reply packet, so
it includes the thread identifier, so it's not a problem packet-wise.
However, GDBserver is currently always reporting the status for first
thread in the thread list, even though that may well not be the thread
that got the signal that caused the program to stop. So the next
logical step would be to report the status for the
last_ptid/last_status thread (the last event reported to gdb), if it's
still around; and if not, fallback to some other thread.
There's an issue on the GDB side with that, though...
GDB currently always adds the thread reported in response to the
status query as the first thread in its list. That means that if we
start with e.g.,
(gdb) info threads
3 Thread 1003 ...
* 2 Thread 1002 ...
1 Thread 1001 ...
And reconnect:
(gdb) disconnect
(gdb) tar rem ...
We end up with:
(gdb) info threads
3 Thread 1003 ...
2 Thread 1001 ...
* 1 Thread 1002 ...
Not a real big issue, but it's reasonably fixable, by having GDB
fetch/sync the thread list before fetching the status/'?', and then
using the status to select the right thread as current on the GDB
side. Holes in the thread numbers are squashed before/after
reconnection (e.g., 2,3,5 becomes 1,2,3), but the order is preserved,
which I think is both good, and good enough.
However (yes, there's more...), the previous GDB that was connected
might have had gdbserver running in non-stop mode, or could have left
gdbserver doing disconnected tracing (which also forces non-stop), and
if the new gdb/connection is in all-stop mode, we can end up with more
than one thread with a signal to report back to gdb. As we can only
report one thread/status (in the all-stop RSP variant; the non-stop
variant doesn't have this issue), we get to do what we do at every
other place we have this situation -- leave events we can't report
right now as pending, so that the next resume picks them up.
Note all this ammounts to a QoI change, within the existing framework.
There's really no RSP change here.
The only user visible change (other than that the signal is program is
stopped at isn't lost / is passed to the program), is in "info
program", that now can show the signal the program stopped for. Of
course, the next resume will respect the pass/nopass setting for the
signal in question. It'd be reasonable to have the initial connection
tell the user the program was stopped with a signal, similar to when
we load a core to debug, but I'm leaving that out for a future change.
I think we'll need to either change how handle_inferior_event & co
handle stop_soon, or maybe bypass them completely (like
fork-child.c:startup_inferior) for that.
Tested on x86_64 Fedora 17.
gdb/gdbserver/
2014-01-08 Pedro Alves <palves@redhat.com>
* gdbthread.h (struct thread_info) <status_pending_p>: New field.
* server.c (visit_actioned_threads, handle_pending_status): New
function.
(handle_v_cont): Factor out parts to ...
(resume): ... this new function. If in all-stop, and a thread
being resumed has a pending status, report it without actually
resuming.
(myresume): Adjust to use the new 'resume' function.
(clear_pending_status_callback, set_pending_status_callback)
(find_status_pending_thread_callback): New functions.
(handle_status): Handle the case of multiple threads having
interesting statuses to report. Report threads' real last signal
instead of always reporting GDB_SIGNAL_TRAP. Look for a thread
with an interesting thread to report the status for, instead of
always reporting the status of the first thread.
gdb/
2014-01-08 Pedro Alves <palves@redhat.com>
* remote.c (remote_add_thread): Add threads silently if starting
up.
(remote_notice_new_inferior): If in all-stop, and starting up,
don't call notice_new_inferior.
(get_current_thread): New function, factored out from ...
(add_current_inferior_and_thread): ... this. Adjust.
(remote_start_remote) <all-stop>: Fetch the thread list. If we
found any thread, then select the remote's current thread as GDB's
current thread too.
gdb/testsuite/
2014-01-08 Pedro Alves <palves@redhat.com>
* gdb.threads/reconnect-signal.c: New file.
* gdb.threads/reconnect-signal.exp: New file.
I noticed something odd while doing "stepi" over a fork syscall:
...
(gdb) set disassemble-next-line on
...
(gdb) si
0x000000323d4ba7c2 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
=> 0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7c4 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
=> 0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
(gdb) si
0x000000323d4ba7ca 131 pid = ARCH_FORK ();
0x000000323d4ba7a4 <__libc_fork+132>: 64 4c 8b 04 25 10 00 00 00 mov %fs:0x10,%r8
0x000000323d4ba7ad <__libc_fork+141>: 31 d2 xor %edx,%edx
0x000000323d4ba7af <__libc_fork+143>: 4d 8d 90 d0 02 00 00 lea 0x2d0(%r8),%r10
0x000000323d4ba7b6 <__libc_fork+150>: 31 f6 xor %esi,%esi
0x000000323d4ba7b8 <__libc_fork+152>: bf 11 00 20 01 mov $0x1200011,%edi
0x000000323d4ba7bd <__libc_fork+157>: b8 38 00 00 00 mov $0x38,%eax
0x000000323d4ba7c2 <__libc_fork+162>: 0f 05 syscall
0x000000323d4ba7c4 <__libc_fork+164>: 48 3d 00 f0 ff ff cmp $0xfffffffffffff000,%rax
=> 0x000000323d4ba7ca <__libc_fork+170>: 0f 87 2b 01 00 00 ja 0x323d4ba8fb <__libc_fork+475>
Notice how the third "si" didn't actually make progress.
Turning on infrun and lin-lwp debug, we see:
(gdb)
infrun: clear_proceed_status_thread (process 5252)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=1)
infrun: resume (step=1, signal=0), trap_expected=0, current thread [process 5252] at 0x323d4ba7c4
LLR: Preparing to step process 5252, 0, inferior_ptid process 5252
RC: Not resuming sibling process 5252 (not stopped)
LLR: PTRACE_SINGLESTEP process 5252, 0 (resume event thread)
sigchld
infrun: wait_for_inferior ()
linux_nat_wait: [process -1], []
LLW: enter
LNW: waitpid(-1, ...) returned 5252, No child processes
LLW: waitpid 5252 received Child exited (stopped)
LLW: Candidate event Child exited (stopped) in process 5252.
SEL: Select single-step process 5252
LLW: exit
infrun: target_wait (-1, status) =
infrun: 5252 [process 5252],
infrun: status->kind = stopped, signal = SIGCHLD
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x323d4ba7c4
infrun: random signal 20
infrun: stepi/nexti
infrun: stop_stepping
So the inferior got a SIGCHLD (because the fork child exited while
we're doing 'si'), and since that signal is set to "nostop noprint
pass" (by default), it's considered a random signal, so it should not
cause a stop. But, it resulted in an immediate a stop_stepping call
anyway. So the single-step never really finished.
This is a regression caused by:
[[PATCH] Do not respawn signals, take 2.]
https://sourceware.org/ml/gdb-patches/2012-06/msg00702.html
Specifically, caused by this change (as mentioned in the "the lost
step issue first" part of that mail):
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 53db335..3e8dbc8 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -4363,10 +4363,8 @@ process_event_stop_test:
(leaving the inferior at the step-resume-breakpoint without
actually executing it). Either way continue until the
breakpoint is really hit. */
- keep_going (ecs);
- return;
}
-
+ else
/* Handle cases caused by hitting a breakpoint. */
{
That made GDB fall through to the
> /* In all-stop mode, if we're currently stepping but have stopped in
> some other thread, we need to switch back to the stepped thread. */
> if (!non_stop)
part. However, if we don't have a stepped thread to get back to,
we'll now also fall through to all the "stepping" tests. For line
stepping, that'll turn out okay, as we'll just end up realizing the
thread is still in the stepping range, and needs to be re-stepped.
However, for stepi/nexti, we'll reach:
if (ecs->event_thread->control.step_range_end == 1)
{
/* It is stepi or nexti. We always want to stop stepping after
one instruction. */
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog, "infrun: stepi/nexti\n");
ecs->event_thread->control.stop_step = 1;
print_end_stepping_range_reason ();
stop_stepping (ecs);
return;
}
and stop, even though the thread actually made no progress. The fix
is to restore the keep_going call, but put it after the "switch back
to the stepped thread" code, and before the stepping tests.
Tested on x86_64 Fedora 17, native and gdbserver. New test included.
gdb/
2013-10-18 Pedro Alves <palves@redhat.com>
PR gdb/16062
* infrun.c (handle_inferior_event): Keep going if we got a random
signal we should not stop for, instead of falling through to the
step tests.
gdb/testsuite/
2013-10-18 Pedro Alves <palves@redhat.com>
PR gdb/16062
* gdb.threads/stepi-random-signal.c: New file.
* gdb.threads/stepi-random-signal.exp: New file.
PR gdb/11568 is about thread-specific breakpoints being left behind
when the corresponding thread exits.
Currently:
(gdb) b start thread 2
Breakpoint 3 at 0x400614: file thread-specific-bp.c, line 23.
(gdb) b end
Breakpoint 4 at 0x40061f: file thread-specific-bp.c, line 29.
(gdb) c
Continuing.
[Thread 0x7ffff7fcb700 (LWP 14925) exited]
[Switching to Thread 0x7ffff7fcc740 (LWP 14921)]
Breakpoint 4, end () at thread-specific-bp.c:29
29 }
(gdb) info threads
Id Target Id Frame
* 1 Thread 0x7ffff7fcc740 (LWP 14921) "thread-specific" end () at thread-specific-bp.c:29
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000400614 in start at thread-specific-bp.c:23
breakpoint already hit 1 time
3 breakpoint keep y 0x0000000000400614 in start at thread-specific-bp.c:23 thread 2
stop only in thread 2
4 breakpoint keep y 0x000000000040061f in end at thread-specific-bp.c:29
breakpoint already hit 1 time
Note that the thread-specific breakpoint 3 stayed around, even though
thread 2 is gone.
There's no way that breakpoint can trigger again (*), so the PR argues
that the breakpoint should just be removed, like local watchpoints.
I'm ambivalent on this -- it could be reasonable to disable the
breakpoint (kind of like breakpoint in shared library code when the
DSO is unloaded), so the user could still use it as visual template
for creating other breakpoints (copy/paste command lists, etc.), or we
could have a way to change to which thread a breakpoint applies. But,
several people pushed this direction, and I don't plan on arguing...
(*) - actually, there is ... thread numbers are reset on "run", so
the user could do "break foo thread 2", "run", and expect the
breakpoint to hit again on the second thread. But given gdb's thread
numbering can't really be stable, that'd only work sufficiently well
for thread 1, so we'd better call it unsupported.
So with the patch, whenever a thread is deleted from GDB's list, GDB
goes through the thread-specific breakpoints and deletes corresponding
breakpoints. Since this is user-visible, GDB prints out:
Thread-specific breakpoint 3 deleted - thread 2 is gone.
And of course, we end up with:
(gdb) info breakpoints
Num Type Disp Enb Address What
2 breakpoint keep y 0x0000000000400614 in start at thread-specific-bp.c:23
breakpoint already hit 1 time
4 breakpoint keep y 0x000000000040061f in end at thread-specific-bp.c:29
breakpoint already hit 1 time
2013-09-17 Muhammad Waqas <mwaqas@codesourcery.com>
Pedro Alves <palves@redhat.com>
PR gdb/11568
* breakpoint.c (remove_threaded_breakpoints): New function.
(_initialize_breakpoint): Attach remove_threaded_breakpoints
as thread_exit observer.
2013-09-17 Muhammad Waqas <mwaqas@codesourccery.com>
Jan Kratochvil <jan.kartochvil@redhat.com>
Pedro Alves <palves@redhat.com>
PR gdb/11568
* gdb.thread/thread-specific-bp.c: New file.
* gdb.thread/thread-specific-bp.exp: New file.
"info threads" changes the default source for "break" and "list", to
whatever the location of the first/bottom thread in the thread list
is...
(gdb) b start
(gdb) c
...
(gdb) list
*lists "start"*
(gdb) b 23
Breakpoint 3 at 0x400614: file test.c, line 23.
(gdb) info threads
Id Target Id Frame
* 2 Thread 0x7ffff7fcb700 (LWP 1760) "test" start (arg=0x0) at test.c:23
1 Thread 0x7ffff7fcc740 (LWP 1748) "test" 0x000000323dc08e60 in pthread_join (threadid=140737353922304, thread_return=0x0) at pthread_join.c:93
(gdb) b 23
Breakpoint 4 at 0x323dc08d90: file pthread_join.c, line 23.
^^^^^^^^^^^^^^^
(gdb) list
93 lll_wait_tid (pd->tid);
94
95
96 /* Restore cancellation mode. */
97 CANCEL_RESET (oldtype);
98
99 /* Remove the handler. */
100 pthread_cleanup_pop (0);
101
102
The issue is that print_stack_frame always sets the current sal to the
frame's sal. print_frame_info (which print_stack_frame calls to do
most of the work) also sets the last displayed sal, but only if
print_what isn't LOCATION. Now the call in question, from within
thread.c:print_thread_info, does pass in LOCATION as print_what, but
print_stack_frame doesn't have the same check print_frame_info has.
We could consider adding it, but setting these globals depending on
print_what isn't very clean, IMO. What we have is two logically
distinct operations mixed in the same function(s):
#1 - print frame, in the format specified by {print_what,
print_level and print_args}.
#2 - We're displaying a frame to the user, and I want the default
sal to point here, because the program stopped here, or the user
did some context-changing command (up, down, etc.).
So I added a new parameter to print_stack_frame & friends for point
#2, and went through all calls in the tree adjusting as necessary.
Tested on x86_64 Fedora 17.
gdb/
2013-09-17 Pedro Alves <palves@redhat.com>
PR gdb/15911
* ada-tasks.c (task_command_1): Adjust call to print_stack_frame.
* bsd-kvm.c (bsd_kvm_open, bsd_kvm_proc_cmd, bsd_kvm_pcb_cmd):
* corelow.c (core_open):
* frame.h (print_stack_frame, print_frame_info): New
'set_current_sal' parameter.
* infcmd.c (finish_command, kill_command): Adjust call to
print_stack_frame.
* inferior.c (inferior_command): Likewise.
* infrun.c (normal_stop): Likewise.
* linux-fork.c (linux_fork_context): Likewise.
* record-full.c (record_full_goto_entry, record_full_restore):
Likewise.
* remote-mips.c (common_open): Likewise.
* stack.c (print_stack_frame): New 'set_current_sal' parameter.
Use it.
(print_frame_info): New 'set_current_sal' parameter. Set the last
displayed sal depending on the new paremeter instead of looking at
print_what.
(backtrace_command_1, select_and_print_frame, frame_command)
(current_frame_command, up_command, down_command): Adjust call to
print_stack_frame.
* thread.c (print_thread_info, restore_selected_frame)
(do_captured_thread_select): Adjust call to print_stack_frame.
* tracepoint.c (tfind_1): Likewise.
* mi/mi-cmd-stack.c (mi_cmd_stack_list_frames)
(mi_cmd_stack_info_frame): Likewise.
* mi/mi-interp.c (mi_on_normal_stop): Likewise.
* mi/mi-main.c (mi_cmd_exec_return, mi_cmd_trace_find): Likewise.
gdb/testsuite/
* gdb.threads/info-threads-cur-sal-2.c: New file.
* gdb.threads/info-threads-cur-sal.c: New file.
* gdb.threads/info-threads-cur-sal.exp: New file.
On Ubuntu by default the compiler passes --as-needed to ld which
means no DT_NEEDED entry is added for libpthread when building
the TLS tests. This causes the test to fail as libpthread is
required to look up TLS variables. Add calls to pthread_testcancel
to make sure libpthread gets linked.
gdb/testsuite/ChangeLog:
2013-07-18 Will Newton <will.newton@linaro.org>
* gdb.threads/tls-nodebug.c: Call pthread_testcancel
to ensure the test is linked against pthreads.
* gdb.threads/tls-var-main.c: Likewise.
* gdb.threads/tls-shared.c: Likewise.
PR threads/13217
* thread.c (thread_apply_all_command): Check for valid threads
and thread count.
(thread_array_cleanup): New struct.
(set_thread_refcount): New function.
Gary Benson <gbenson@redhat.com>
* lib/gdb.exp (build_executable_from_specs): Use gdb_compile_pthread,
gdb_compile_shlib or gdb_compile_shlib_pthreads where appropriate.
* lib/prelink-support.exp (build_executable_own_libs): Allow INTERP
to be set to "no" to indicate that no ld.so copy should be made.
* gdb.base/break-interp.exp (solib_bp): New constant.
(reach_1): Use the above instead of "_dl_debug_state".
(test_attach): Likewise.
(test_ld): Likewise.
* gdb.threads/dlopen-libpthread.exp: New file.
* gdb.threads/dlopen-libpthread.c: Likewise.
* gdb.threads/dlopen-libpthread-lib.c: Likewise.
* gdb.base/solib-corrupted.exp: Disable test if GDB is using probes.
* ppc-linux-nat.c (ppc_linux_new_thread): Clear the new thread's
debug state prior to replicating existing hardware watchpoints or
breakpoints.
gdb/testsuite/
* gdb.threads/wp-replication.c: New file.
* gdb.threads/wp-replication.exp: New file.
Two modifications:
1. The addition of 2013 to the copyright year range for every file;
2. The use of a single year range, instead of potentially multiple
year ranges, as approved by the FSF.
Update some files in GDB that were accidently left with a GPL v2
copyright header.
Update some files where the copyright notice still provides the
old contact info, using the approach for providing the FSF's contact
info.
gdb/ChangeLog:
* acinclude.m4: Update contact info in copyright notice.
gdb/doc/ChangeLog:
* refcard.tex: Update copyright notice to GPL v3 or later.
Update contact info.
gdb/testsuite/ChangeLog:
* dg-extract-results.sh: Update contact info in copyright notice.
* gdb.arch/mips-octeon-bbit.exp: Update copyright notice to
GPL v3 or later. Update contact info.
* gdb.fortran/logical.f90, gdb.threads/watchpoint-fork-child.c,
gdb.threads/watchpoint-fork-mt.c,
gdb.threads/watchpoint-fork-parent.c,
gdb.threads/watchpoint-fork-st.c,
gdb.threads/watchpoint-fork.h: Likewise.
2012-11-14 Yao Qi <yao@codesourcery.com>
* gdb.threads/manythreads.c [DEBUG]: Include "stdio.h".
(thread_function) [DEBUG]: Call 'printf'.
* gdb.threads/manythreads.exp: Pass '-DDEBUG' to compilation
command line if 'DEBUG=1' is passed to test.
Remove a pattern to match inferior's output.
* gdb.python/py-strfns.exp (test_strfns_core_file): Use
gdb_gcore_cmd.
* gdb.cell/gcore.exp: Use gdb_gcore_cmd.
* gdb.base/gcore.exp: Use gdb_gcore_cmd.
* gdb.base/gcore-relro.exp: Use gdb_gcore_cmd.
* gdb.base/gcore-buffer-overflow.exp: Use gdb_gcore_cmd.
* gdb.base/auxv.exp: Use gdb_gcore_cmd.
* gdb.arch/vsx-regs.exp: Use gdb_gcore_cmd.
* gdb.arch/system-gcore.exp: Use gdb_gcore_cmd.
* gdb.arch/pa-nullify.exp (test_core_bt): Use gdb_gcore_cmd.
* lib/gdb.exp (gdb_gcore_cmd): New proc.
when starting up the program.
* gdb.python/py-value.exp (test_value_numeric_ops): Pointers may
show a symbolic value as well.
* gdb.server/server-exec-info.exp: Skip test when skipping
gdbserver test and/or when skipping shared library tests.
* gdb.threads/linux-dp.exp: Unset "seen" when done with it to
avoid name conflicts with other tests.
PR threads/11692
PR gdb/12203
gdb/
* infrun.c (handle_inferior_event) <new thread>: Don't special
case minus_one_ptid.
<TARGET_WAITKIND_SPURIOUS>: Ditto.
* linux-thread-db.c (thread_get_info_callback): Don't return early
if the thread is zombie.
(thread_from_lwp): Change return type to void. Rewrite stale
comment.
(attach_thread): Don't return early if the thread is zombie,
instead set its "dying" flag.
(thread_db_wait): Don't return TARGET_WAITKIND_SPURIOUS anymore.
(find_new_threads_callback): Don't return early if the thread is
zombie.
gdb/testsuite/
* gdb.threads/create-fail.c: New file.
* gdb.threads/create-fail.exp: New file.
* linux-thread-db.c (inferior_has_bug): New function.
(thread_db_find_new_threads_silently): Return boolean as checked by
inferior_has_bug, describe it in the comments.
(try_thread_db_load_1): Move call to thread_db_find_new_threads_silently
earlier. Abort the initialization if it returned non-zero.
(thread_db_find_new_threads_2): Preinitialize ERR. Check errors also
if UNTIL_NO_NEW,
gdb/testsuite/
* gdb.threads/gcore-thread.exp: Remove variable libthread_db_seen.
Wrap the test into loop for corefile and core0file.
2012-06-28 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_THREADS): New macro.
(thread_list): Declare.
* infrun.c (handle_inferior_event) <spurious signal>: Don't keep
going, but instead fall through to the stepping handling.
* linux-nat.c (resume_lwp): New parameter 'signo'. Resume with
the passed in signal. Adjust debug output.
(resume_callback): Rename to ...
(linux_nat_resume_callback): ... this. Pass the thread's last
stop signal, if in "pass" state.
(linux_nat_resume): Adjust to rename.
(stop_wait_callback): New assertion. Don't respawn signals;
instead let the LWP remain with SIGNALLED set.
(linux_nat_wait_1): Remove flushing of pending SIGSTOPs.
* remote.c (append_pending_thread_resumptions): New.
(remote_vcont_resume): Call it.
* target.h (target_resume): Extend comment.
gdb/testsuite/
2012-06-28 Jan Kratochvil <jan.kratochvil@redhat.com>
Pedro Alves <palves@redhat.com>
* gdb.threads/siginfo-threads.exp: New file.
* gdb.threads/siginfo-threads.c: New file.
* gdb.threads/sigstep-threads.exp: New file.
* gdb.threads/sigstep-threads.c: New file.
2012-06-06 Pedro Alves <palves@redhat.com>
* infrun.c (struct execution_control_state): Remove
`new_thread_event' field.
(handle_inferior_event): Simplify new threads handling; don't
resume the inferior if we find a new thread.
gdb/testsuite/
2012-06-06 Pedro Alves <palves@redhat.com>
* gdb.threads/clone-new-thread-event.c: New file.
* gdb.threads/clone-new-thread-event.exp: New file.
Tom Tromey <tromey@redhat.com>
* lib/gdb.exp: Add description of test prefixes.
(with_test_prefix): New procedure.
* gdb.arch/altivec-abi.exp: Use with_test_prefix.
* gdb.base/attach-pie-misread.exp: Use with_test_prefix.
* gdb.base/break-interp.exp: Use with_test_prefix. Use append
instead of lappend to append to pf_prefix.
* gdb.base/catch-load.exp: Use with_test_prefix.
* gdb.base/disp-step-syscall.exp: Use with_test_prefix.
* gdb.base/jit-so.exp: Use with_test_prefix.
* gdb.base/jit.exp: Use with_test_prefix.
* gdb.base/return-nodebug.exp (do_test): Use append instead of
lappend to append to pf_prefix.
* gdb.base/sepdebug.exp: Use with_test_prefix.
* gdb.base/solib-display.exp: Use with_test_prefix.
* gdb.base/solib-overlap.exp: Use with_test_prefix.
* gdb.base/watch-cond-infcall.exp: Use with_test_prefix.
* gdb.base/watchpoint.exp: Use with_test_prefix.
* gdb.dwarf2/dw2-noloc.exp: Use with_test_prefix.
* gdb.mi/mi-watch.exp: Use with_test_prefix.
* gdb.mi/mi2-watch.exp: Use with_test_prefix.
* gdb.threads/non-ldr-exc-1.exp: Use with_test_prefix.
* gdb.threads/non-ldr-exc-2.exp: Use with_test_prefix.
* gdb.threads/non-ldr-exc-3.exp: Use with_test_prefix.
* gdb.threads/non-ldr-exc-4.exp: Use with_test_prefix.
* gdb.threads/watchpoint-fork.exp: Use with_test_prefix. Use
append instead of lappend to append to pf_prefix.
* gdb.threads/watchthreads-reorder.exp: Use with_test_prefix.
* gdb.trace/change-loc.exp: Use with_test_prefix.
* gdb.trace/pending.exp: Use with_test_prefix.
* gdb.trace/status-stop.exp: Use with_test_prefix.
* gdb.trace/strace.exp: Use with_test_prefix.
* gdb.trace/trace-break.exp: Use with_test_prefix.
* gdb.trace/unavailable.exp: Use with_test_prefix. Use append
instead of lappend to append to pf_prefix.
* gdb.threads/attach-into-signal.exp (corefunc): Don't enable
lin-lwp output. Set SIGALRM to stop. Adjust tests to not rely on
gdb's internal debug output. For the non-threaded case, look for
"Program received signal SIGLARM", for the threaded case, peek at
the thread's siginfo.
General cleanup, make output test messages unique, and build
different executable files for the non-threaded and threaded
cases.
* gdb.threads/attach-into-signal.exp (binfile, escapedbinfile):
Delete.
(executable_nothr, executable_thr): New globals.
(top level): Adjust to delete both executables.
(corefunc): New parameter $executable. Set $pf_prefix instead of
hand writing a prefix in tests. Issue a clean_restart and enable
lin-lwp debug output here.
(top level): Adjust. Use build_executable. Don't start gdb here,
and don't enable lin-lwp debug output here.
* gdb.threads/Makefile.in (EXECUTABLES): Adjust.
Fix watchpoints across inferior fork.
* amd64-linux-nat.c (update_debug_registers_callback): Update the
comment for linux_nat_iterate_watchpoint_lwps.
(amd64_linux_dr_set_control, amd64_linux_dr_set_addr): Use
linux_nat_iterate_watchpoint_lwps.
(amd64_linux_prepare_to_resume): New comment on Linux kernel.
* i386-linux-nat.c (update_debug_registers_callback): Update the
comment for linux_nat_iterate_watchpoint_lwps.
(i386_linux_dr_set_control, i386_linux_dr_set_addr): Use
linux_nat_iterate_watchpoint_lwps.
(i386_linux_prepare_to_resume): New comment on Linux kernel.
* i386-nat.c: Include inferior.h.
(dr_mirror): Remove.
(i386_inferior_data, struct i386_inferior_data)
(i386_inferior_data_get): New.
(i386_debug_reg_state): Use i386_inferior_data_get.
(i386_cleanup_dregs, i386_update_inferior_debug_regs)
(i386_insert_watchpoint, i386_remove_watchpoint)
(i386_stopped_data_address, i386_insert_hw_breakpoint)
(i386_remove_hw_breakpoint): New variable state, use
i386_debug_reg_state instead of DR_MIRROR.
* linux-nat.c (delete_lwp): New declaration.
(num_lwps): Move here from downwards.
(delete_lwp_cleanup): New.
(linux_child_follow_fork): Create new child_lp, call
linux_nat_new_thread and linux_nat_prepare_to_resume before calling
PTRACE_DETACH.
(num_lwps): Move upwards.
(linux_nat_iterate_watchpoint_lwps): New.
* linux-nat.h (linux_nat_iterate_watchpoint_lwps_ftype): New.
(linux_nat_iterate_watchpoint_lwps_ftype): New declaration.
gdb/testsuite/
Fix watchpoints across inferior fork.
* gdb.threads/watchpoint-fork-child.c: New file.
* gdb.threads/watchpoint-fork-mt.c: New file.
* gdb.threads/watchpoint-fork-parent.c: New file.
* gdb.threads/watchpoint-fork-st.c: New file.
* gdb.threads/watchpoint-fork.exp: New file.
* gdb.threads/watchpoint-fork.h: New file.
Fix racy FAILs.
* gdb.threads/fork-thread-pending.c (barrier): New variable.
(thread_function, thread_forker): Call pthread_barrier_wait for it.
(main): Call pthread_barrier_init for it.
PR threads/13448
* dwarf2read.c (decode_locdesc): Handle DW_OP_const8u.
For DW_OP_GNU_push_tls_address increment the value, new comment for it.
gdb/testsuite/
PR threads/13448
* gdb.dwarf2/dw2-var-zero-addr.S: New file.
* gdb.dwarf2/dw2-var-zero-addr.exp: New file.
* gdb.threads/tls-var-main.c: New file.
* gdb.threads/tls-var.c: New file.
* gdb.threads/tls-var.exp: New file.
