On GNU/Linux, if the running kernel supports clone events, then
linux-thread-db.c defers thread listing to the target beneath:
static void
thread_db_update_thread_list (struct target_ops *ops)
{
...
if (target_has_execution && !thread_db_use_events ())
ops->beneath->to_update_thread_list (ops->beneath);
else
thread_db_update_thread_list_td_ta_thr_iter (ops);
...
}
However, when live debugging, the target beneath, linux-nat.c, does
not implement the to_update_thread_list method. The result is that if
a thread is marked exited (because it can't be deleted right now,
e.g., it was the selected thread), then it won't ever be deleted,
until the process exits or is killed/detached.
A similar thing happens with the remote.c target. Because its
target_update_thread_list implementation skips exited threads when it
walks the current thread list looking for threads that no longer exits
on the target side, using ALL_NON_EXITED_THREADS_SAFE, stale exited
threads are never deleted.
This is not a big deal -- I can't think of any way this might be user
visible, other than gdb's memory growing a tiny bit whenever a thread
gets stuck in exited state. Still, might as well clean things up
properly.
All other targets use prune_threads, so are unaffected.
The fix adds a ALL_THREADS_SAFE macro, that like
ALL_NON_EXITED_THREADS_SAFE, walks the thread list and allows deleting
the iterated thread, and uses that in places that are walking the
thread list in order to delete threads. Actually, after converting
linux-nat.c and remote.c to use this, we find the only other user of
ALL_NON_EXITED_THREADS_SAFE is also walking the list to delete
threads. So we convert that too, and end up deleting
ALL_NON_EXITED_THREADS_SAFE.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog
2015-04-07 Pedro Alves <palves@redhat.com>
* gdbthread.h (ALL_NON_EXITED_THREADS_SAFE): Rename to ...
(ALL_THREADS_SAFE): ... this, and don't skip exited threads.
(delete_exited_threads): New declaration.
* infrun.c (follow_exec): Use ALL_THREADS_SAFE.
* linux-nat.c (linux_nat_update_thread_list): New function.
(linux_nat_add_target): Install it.
* remote.c (remote_update_thread_list): Use ALL_THREADS_SAFE.
* thread.c (prune_threads): Use ALL_THREADS_SAFE.
(delete_exited_threads): New function.
My all-stop-on-top-of-non-stop series manages to trip on a bug in the
linux-nat.c backend while running the testsuite. If a thread is
discovered while threads are being momentarily paused (without the
core's intervention), the thread ends up stuck in THREAD_STOPPED
state, even though from the user's perspective, the thread is running
even while it is paused.
From inspection, in the current sources, this can happen if we call
stop_and_resume_callback, though there's no way to test that with
current Linux kernels.
(While trying to come up with test to exercise this, I stumbled on:
https://sourceware.org/ml/gdb-patches/2015-03/msg00850.html
... which does include a non-trivial test, so I think I can still
claim I come out net positive. :-) )
Tested on x86_64 Fedora 20.
gdb/ChangeLog:
2015-04-01 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait): Always call set_running.
All callers of target_async pass it the same callback
(inferior_event_handler). Since both common code and target backends
need to be able to put the target in and out of target async mode at
any given time, there's really no way that a different callback could
be passed. This commit simplifies things, and removes the indirection
altogether. Bonus: with this, gdb's target_async method ends up with
the same signature as gdbserver's.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/ChangeLog:
2015-03-25 Pedro Alves <palves@redhat.com>
* target.h <to_async>: Replace 'callback' and 'context' parameters
with boolean 'enable' parameter.
(target_async): Replace CALLBACK and CONTEXT parameters with
boolean ENABLE parameter.
* inf-loop.c (inferior_event_handler): Adjust.
* linux-nat.c (linux_nat_attach, linux_nat_resume)
(linux_nat_resume): Adjust.
(async_client_callback, async_client_context): Delete.
(handle_target_event): Call inferior_event_handler directly.
(linux_nat_async): Replace 'callback' and 'context' parameters
with boolean 'enable' parameter. Adjust. Remove references to
async_client_callback and async_client_context.
(linux_nat_close): Adjust.
* record-btrace.c (record_btrace_async): Replace 'callback' and
'context' parameters with boolean 'enable' parameter. Adjust.
(record_btrace_resume): Adjust.
* record-full.c (record_full_async): Replace 'callback' and
'context' parameters with boolean 'enable' parameter. Adjust.
(record_full_resume, record_full_core_resume): Adjust.
* remote.c (struct remote_state) <async_client_callback,
async_client_context>: Delete fields.
(remote_start_remote, extended_remote_attach_1, remote_resume)
(extended_remote_create_inferior): Adjust.
(remote_async_serial_handler): Call inferior_event_handler
directly.
(remote_async): Replace 'callback' and 'context' parameters with
boolean 'enable' parameter. Adjust.
* top.c (gdb_readline_wrapper_cleanup, gdb_readline_wrapper):
Adjust.
* target-delegates.c: Regenerate.
This adds/tweaks a few debug logs I found useful recently.
gdb/gdbserver/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* linux-low.c (check_stopped_by_breakpoint): Tweak debug log
output. Also dump TRAP_TRACE.
(linux_low_filter_event): In debug output, distinguish a
resume_stop SIGSTOP from a delayed SIGSTOP.
gdb/ChangeLog:
2015-03-24 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_nat_resume): Output debug logs before trying
to resume the event lwp. Use the lwp's ptid instead of the passed
in (maybe wildcard) ptid.
(stop_wait_callback): Tweak debug log output.
(check_stopped_by_breakpoint): Tweak debug log output. Also dump
TRAP_TRACE.
(linux_nat_filter_event): In debug output, distinguish a
resume_stop SIGSTOP from a delayed SIGSTOP. Output debug logs
before trying to resume the lwp.
This commit moves the code to handle lwp_info.arch_private for
Linux x86 into a new shared file, nat/x86-linux.c.
gdb/ChangeLog:
* nat/x86-linux.h: New file.
* nat/x86-linux.c: Likewise.
* Makefile.in (HFILES_NO_SRCDIR): Add nat/x86-linux.h.
(x86-linux.o): New rule.
* config/i386/linux.mh (NATDEPFILES): Add x86-linux.o.
* config/i386/linux64.mh (NATDEPFILES): Likewise.
* nat/linux-nat.h (struct arch_lwp_info): New forward declaration.
(lwp_set_arch_private_info): New declaration.
(lwp_arch_private_info): Likewise.
* linux-nat.c (lwp_set_arch_private_info): New function.
(lwp_arch_private_info): Likewise.
* x86-linux-nat.c: Include nat/x86-linux.h.
(arch_lwp_info): Removed structure.
(update_debug_registers_callback):
Use lwp_set_debug_registers_changed.
(x86_linux_prepare_to_resume): Use lwp_debug_registers_changed
and lwp_set_debug_registers_changed.
(x86_linux_new_thread): Use lwp_set_debug_registers_changed.
gdb/gdbserver/ChangeLog:
* Makefile.in (x86-linux.o): New rule.
* configure.srv: Add x86-linux.o to relevant targets.
* linux-low.c (lwp_set_arch_private_info): New function.
(lwp_arch_private_info): Likewise.
* linux-x86-low.c: Include nat/x86-linux.h.
(arch_lwp_info): Removed structure.
(update_debug_registers_callback):
Use lwp_set_debug_registers_changed.
(x86_linux_prepare_to_resume): Use lwp_debug_registers_changed
and lwp_set_debug_registers_changed.
(x86_linux_new_thread): Use lwp_set_debug_registers_changed.
This commit introduces three accessors that shared Linux code can
use to access fields of struct lwp_info. The GDB and gdbserver
Linux x86 code is modified to use them.
gdb/ChangeLog:
* nat/linux-nat.h (ptid_of_lwp): New declaration.
(lwp_is_stopped): Likewise.
(lwp_stop_reason): Likewise.
* linux-nat.c (ptid_of_lwp): New function.
(lwp_is_stopped): Likewise.
(lwp_is_stopped_by_watchpoint): Likewise.
* x86-linux-nat.c (update_debug_registers_callback):
Use lwp_is_stopped.
(x86_linux_prepare_to_resume): Use ptid_of_lwp and
lwp_stop_reason.
gdb/gdbserver/ChangeLog:
* linux-low.c (ptid_of_lwp): New function.
(lwp_is_stopped): Likewise.
(lwp_stop_reason): Likewise.
* linux-x86-low.c (update_debug_registers_callback):
Use lwp_is_stopped.
(x86_linux_prepare_to_resume): Use ptid_of_lwp and
lwp_stop_reason.
This commit introduces a new function, iterate_over_lwps, that
shared Linux code can use to call a function for each LWP that
matches certain criteria. This function already existed in GDB
and was in use by GDB's various low-level Linux x86 debug register
setters. An equivalent was written for gdbserver and gdbserver's
low-level Linux x86 debug register setters were modified to use
it.
gdb/ChangeLog:
* linux-nat.h: Include nat/linux-nat.h.
(iterate_over_lwps): Move declaration to nat/linux-nat.h.
* nat/linux-nat.h (struct lwp_info): New forward declaration.
(iterate_over_lwps_ftype): New typedef.
(iterate_over_lwps): New declaration.
* linux-nat.h (iterate_over_lwps): Update comment. Use
iterate_over_lwps_ftype. Update callback return value check.
gdb/gdbserver/ChangeLog:
* linux-low.h: Include nat/linux-nat.h.
* linux-low.c (iterate_over_lwps_args): New structure.
(iterate_over_lwps_filter): New function.
(iterate_over_lwps): Likewise.
* linux-x86-low.c (update_debug_registers_callback):
Update signature to what iterate_over_lwps expects.
Remove PID check that iterate_over_lwps now performs.
(x86_dr_low_set_addr): Use iterate_over_lwps.
(x86_dr_low_set_control): Likewise.
This commit introduces a new function, current_lwp_ptid, that
shared Linux code can use to obtain the ptid of the current
lightweight process.
gdb/ChangeLog:
* nat/linux-nat.h (current_lwp_ptid): New declaration.
* linux-nat.c (current_lwp_ptid): New function.
* x86-linux-nat.c: Include nat/linux-nat.h.
(x86_linux_dr_get_addr): Use current_lwp_ptid.
(x86_linux_dr_get_control): Likewise.
(x86_linux_dr_get_status): Likewise.
(x86_linux_dr_set_control): Likewise.
(x86_linux_dr_set_addr): Likewise.
gdb/gdbserver/ChangeLog:
* linux-low.c (current_lwp_ptid): New function.
* linux-x86-low.c: Include nat/linux-nat.h.
(x86_dr_low_get_addr): Use current_lwp_ptid.
(x86_dr_low_get_control): Likewise.
(x86_dr_low_get_status): Likewise.
On GNU/Linux, this test sometimes FAILs like this:
(gdb) run
Starting program: /home/pedro/gdb/mygit/build/gdb/testsuite/gdb.threads/killed
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
ptrace: No such process.
(gdb)
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
FAIL: gdb.threads/killed.exp: run program to completion (timeout)
Note the suspicious "No such process" line (that's errno==ESRCH).
Adding debug output we see:
linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 18465, ERRNO-OK
LLW: waitpid 18465 received Stopped (signal) (stopped)
LNW: waitpid(-1, ...) returned 18461, ERRNO-OK
LLW: waitpid 18461 received Trace/breakpoint trap (stopped)
LLW: Handling extended status 0x03057f
LHEW: Got clone event from LWP 18461, new child is LWP 18465
LNW: waitpid(-1, ...) returned 0, ERRNO-OK
RSRL: resuming stopped-resumed LWP LWP 18465 at 0x3b36af4b51: step=0
RSRL: resuming stopped-resumed LWP LWP 18461 at 0x3b36af4b51: step=0
sigchld
ptrace: No such process.
(gdb) linux_nat_wait: [process -1], [TARGET_WNOHANG]
LLW: enter
LNW: waitpid(-1, ...) returned 18465, ERRNO-OK
LLW: waitpid 18465 received Killed (terminated)
LLW: LWP 18465 exited.
LNW: waitpid(-1, ...) returned 18461, No child processes
LLW: waitpid 18461 received Killed (terminated)
Process 18461 exited
LNW: waitpid(-1, ...) returned -1, No child processes
LLW: exit
sigchld
infrun: target_wait (-1, status) =
infrun: 18461 [process 18461],
infrun: status->kind = signalled, signal = GDB_SIGNAL_KILL
infrun: TARGET_WAITKIND_SIGNALLED
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
infrun: stop_waiting
FAIL: gdb.threads/killed.exp: run program to completion (timeout)
The issue is that here:
RSRL: resuming stopped-resumed LWP LWP 18465 at 0x3b36af4b51: step=0
RSRL: resuming stopped-resumed LWP LWP 18461 at 0x3b36af4b51: step=0
The first line shows we had just resumed LWP 18465, which does:
void *
child_func (void *dummy)
{
kill (pid, SIGKILL);
exit (1);
}
So if the kernel manages to schedule that thread fast enough, the
process may be killed before GDB has a chance to resume LWP 18461.
GDBserver has code at the tail end of linux_resume_one_lwp to cope
with this:
~~~
ptrace (step ? PTRACE_SINGLESTEP : PTRACE_CONT, lwpid_of (thread),
(PTRACE_TYPE_ARG3) 0,
/* Coerce to a uintptr_t first to avoid potential gcc warning
of coercing an 8 byte integer to a 4 byte pointer. */
(PTRACE_TYPE_ARG4) (uintptr_t) signal);
current_thread = saved_thread;
if (errno)
{
/* ESRCH from ptrace either means that the thread was already
running (an error) or that it is gone (a race condition). If
it's gone, we will get a notification the next time we wait,
so we can ignore the error. We could differentiate these
two, but it's tricky without waiting; the thread still exists
as a zombie, so sending it signal 0 would succeed. So just
ignore ESRCH. */
if (errno == ESRCH)
return;
perror_with_name ("ptrace");
}
~~~
However, that's not a complete fix, because between starting to handle
the resume request and getting that PTRACE_CONTINUE, we run other
ptrace calls that can also fail with ESRCH, and that end up throwing
an error (with perror_with_name).
In the case above, I indeed sometimes see resume_stopped_resumed_lwps
fail in the registers read:
resume_stopped_resumed_lwps (struct lwp_info *lp, void *data)
{
...
CORE_ADDR pc = regcache_read_pc (regcache);
Or e.g., in 32-bit mode, i386_linux_resume has several calls that can
throw too.
Whether to ignore ptrace errors or not depends on context that is only
available somewhere up the call chain. So the fix is to let ptrace
errors throw as they do today, and wrap the resume request in a
TRY/CATCH that swallows it iff the lwp that we were trying to resume
is no longer ptrace-stopped.
gdb/gdbserver/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_resume_one_lwp): Rename to ...
(linux_resume_one_lwp_throw): ... this. Don't handle ESRCH here,
instead call perror_with_name.
(check_ptrace_stopped_lwp_gone): New function.
(linux_resume_one_lwp): Reimplement as wrapper around
linux_resume_one_lwp_throw that swallows errors if the LWP is
gone.
gdb/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_resume_one_lwp): Rename to ...
(linux_resume_one_lwp_throw): ... this. Don't handle ESRCH here,
instead call perror_with_name.
(check_ptrace_stopped_lwp_gone): New function.
(linux_resume_one_lwp): Reimplement as wrapper around
linux_resume_one_lwp_throw that swallows errors if the LWP is
gone.
(resume_stopped_resumed_lwps): Try register reads in TRY/CATCH and
swallows errors if the LWP is gone. Use
linux_resume_one_lwp_throw instead of linux_resume_one_lwp.
Wanting to make sure the new continue-pending-status.exp test tests
both cases of threads 2 and 3 reporting an event, I added counters to
the test, to make it FAIL if events for both threads aren't seen.
Assuming a well behaved backend, and given a reasonable number of
iterations, it should PASS.
However, running that against GNU/Linux gdbserver, I found that
surprisingly, that FAILed. GDBserver always reported the breakpoint
hit for the same thread.
Turns out that I broke gdbserver's thread event randomization
recently, with git commit 582511be ([gdbserver] linux-low.c: better
starvation avoidance, handle non-stop mode too). In that commit I
missed that the thread structure also has a status_pending_p field...
The end result was that count_events_callback always returns 0, and
then if no thread is stepping, select_event_lwp always returns the
event thread. IOW, no randomization is happening at all. Quite
curious how all the other changes in that patch were sufficient to fix
non-stop-fair-events.exp anyway even with that broken.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/gdbserver/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-low.c (count_events_callback, select_event_lwp_callback):
Use the lwp's status_pending_p field, not the thread's.
gdb/testsuite/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-status.exp (saw_thread_2)
(saw_thread_3): New globals.
(top level): Increment them when an event for the corresponding
thread is seen.
(no thread starvation): New test.
If the linux_nat_resume's short-circuits the resume because the
current thread has a pending status, and, a thread with a higher
number was previously stopped for a breakpoint, GDB internal errors,
like:
/home/pedro/gdb/mygit/src/gdb/linux-nat.c:2590: internal-error: status_callback: Assertion `lp->status != 0' failed.
Fix this by make status_callback bail out earlier. GDBserver is
already doing the same.
New test added that exercises this.
gdb/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-nat.c (status_callback): Return early if the LWP has no
status pending.
gdb/testsuite/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-status.c: New file.
* gdb.threads/continue-pending-status.exp: New file.
This function (in both GDB and GDBserver) used to consider only
SIGTRAP/breakpoint events, but that's no longer the case nowadays.
gdb/gdbserver/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-low.c (select_event_lwp_callback): Update comments to
no longer mention SIGTRAP.
gdb/ChangeLog:
2015-03-19 Pedro Alves <palves@redhat.com>
* linux-nat.c (select_event_lwp_callback): Update comment to no
longer mention SIGTRAP.
This patch splits the TRY_CATCH macro into three, so that we go from
this:
~~~
volatile gdb_exception ex;
TRY_CATCH (ex, RETURN_MASK_ERROR)
{
}
if (ex.reason < 0)
{
}
~~~
to this:
~~~
TRY
{
}
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
~~~
Thus, we'll be getting rid of the local volatile exception object, and
declaring the caught exception in the catch block.
This allows reimplementing TRY/CATCH in terms of C++ exceptions when
building in C++ mode, while still allowing to build GDB in C mode
(using setjmp/longjmp), as a transition step.
TBC, after this patch, is it _not_ valid to have code between the TRY
and the CATCH blocks, like:
TRY
{
}
// some code here.
CATCH (ex, RETURN_MASK_ERROR)
{
}
END_CATCH
Just like it isn't valid to do that with C++'s native try/catch.
By switching to creating the exception object inside the CATCH block
scope, we can get rid of all the explicitly allocated volatile
exception objects all over the tree, and map the CATCH block more
directly to C++'s catch blocks.
The majority of the TRY_CATCH -> TRY+CATCH+END_CATCH conversion was
done with a script, rerun from scratch at every rebase, no manual
editing involved. After the mechanical conversion, a few places
needed manual intervention, to fix preexisting cases where we were
using the exception object outside of the TRY_CATCH block, and cases
where we were using "else" after a 'if (ex.reason) < 0)' [a CATCH
after this patch]. The result was folded into this patch so that GDB
still builds at each incremental step.
END_CATCH is necessary for two reasons:
First, because we name the exception object in the CATCH block, which
requires creating a scope, which in turn must be closed somewhere.
Declaring the exception variable in the initializer field of a for
block, like:
#define CATCH(EXCEPTION, mask) \
for (struct gdb_exception EXCEPTION; \
exceptions_state_mc_catch (&EXCEPTION, MASK); \
EXCEPTION = exception_none)
would avoid needing END_CATCH, but alas, in C mode, we build with C90,
which doesn't allow mixed declarations and code.
Second, because when TRY/CATCH are wired to real C++ try/catch, as
long as we need to handle cleanup chains, even if there's no CATCH
block that wants to catch the exception, we need for stop at every
frame in the unwind chain and run cleanups, then rethrow. That will
be done in END_CATCH.
After we require C++, we'll still need TRY/CATCH/END_CATCH until
cleanups are completely phased out -- TRY/CATCH in C++ mode will
save/restore the current cleanup chain, like in C mode, and END_CATCH
catches otherwise uncaugh exceptions, runs cleanups and rethrows, so
that C++ cleanups and exceptions can coexist.
IMO, this still makes the TRY/CATCH code look a bit more like a
newcomer would expect, so IMO worth it even if we weren't considering
C++.
gdb/ChangeLog.
2015-03-07 Pedro Alves <palves@redhat.com>
* common/common-exceptions.c (struct catcher) <exception>: No
longer a pointer to volatile exception. Now an exception value.
<mask>: Delete field.
(exceptions_state_mc_init): Remove all parameters. Adjust.
(exceptions_state_mc): No longer pop the catcher here.
(exceptions_state_mc_catch): New function.
(throw_exception): Adjust.
* common/common-exceptions.h (exceptions_state_mc_init): Remove
all parameters.
(exceptions_state_mc_catch): Declare.
(TRY_CATCH): Rename to ...
(TRY): ... this. Remove EXCEPTION and MASK parameters.
(CATCH, END_CATCH): New.
All callers adjusted.
gdb/gdbserver/ChangeLog:
2015-03-07 Pedro Alves <palves@redhat.com>
Adjust all callers of TRY_CATCH to use TRY/CATCH/END_CATCH
instead.
This commit introduces a new inline common function "startswith"
which takes two string arguments and returns nonzero if the first
string starts with the second. It also updates the 295 places
where this logic was written out longhand to use the new function.
gdb/ChangeLog:
* common/common-utils.h (startswith): New inline function.
All places where this logic was used updated to use the above.
record-btrace was the only target making use of this, and it no longer
uses it.
gdb/ChangeLog:
2015-03-04 Pedro Alves <palves@redhat.com>
* target.h (struct target_ops) <to_decr_pc_after_break>: Delete.
(target_decr_pc_after_break): Delete declaration.
* target.c (default_target_decr_pc_after_break)
(target_decr_pc_after_break): Delete.
* linux-nat.c (check_stopped_by_breakpoint, linux_nat_wait_1): Use
gdbarch_decr_pc_after_break instead of target_decr_pc_after_break.
* linux-thread-db.c (check_event): Likewise.
* infrun.c (adjust_pc_after_break): Likewise.
* darwin-nat.c (cancel_breakpoint): Likewise.
* aix-thread.c (aix_thread_wait): Likewise.
* target-delegates.c: Regenerate.
This patch adjusts the native Linux target backend to tell the core
whether a trap was caused by a breakpoint.
It teaches the target to get that information out of the si_code of
the SIGTRAP siginfo.
Tested on x86-64 Fedora 20, s390 RHEL 7, and PPC64 Fedora 18. An
earlier version was tested on ARM Fedora 21.
gdb/ChangeLog:
2015-03-04 Pedro Alves <palves@redhat.com>
* linux-nat.c (save_sigtrap): Check for breakpoints before
checking watchpoints.
(status_callback) [USE_SIGTRAP_SIGINFO]: Don't check whether a
breakpoint is inserted if relying on SIGTRAP's siginfo.si_code.
(check_stopped_by_breakpoint) [USE_SIGTRAP_SIGINFO]: Decide whether
a breakpoint triggered based on the SIGTRAP's siginfo.si_code.
(linux_nat_stopped_by_sw_breakpoint)
(linux_nat_supports_stopped_by_sw_breakpoint)
(linux_nat_stopped_by_hw_breakpoint)
(linux_nat_supports_stopped_by_hw_breakpoint): New functions.
(linux_nat_wait_1): Don't re-increment the PC if relying on
SIGTRAP's siginfo->si_code.
(linux_nat_add_target): Install new target methods.
* linux-thread-db.c (check_event): Don't account for breakpoint PC
offset if the target already adjusted the PC.
* nat/linux-ptrace.h (USE_SIGTRAP_SIGINFO): New.
(GDB_ARCH_TRAP_BRKPT): New.
(TRAP_HWBKPT): Define if not already defined.
This Linuxism has made its way into infrun.c, in the follow-fork code:
inferior_ptid = ptid_build (child_pid, child_pid, 0);
The OS-specific code should fill in the LWPID, TID parts with the
appropriate values, if any, and the core code should not be peeking at
the components of the ptids.
gdb/
2015-03-04 Pedro Alves <palves@redhat.com>
* infrun.c (follow_fork_inferior): Use the whole of the
inferior_ptid and pending_follow.related_pid ptids instead of
building ptids from the process components. Adjust verbose output
to use target_pid_to_str.
* linux-nat.c (linux_child_follow_fork): Use the whole of the
inferior_ptid and pending_follow.related_pid ptids instead of
building ptids from the process components.
Ref: https://sourceware.org/ml/gdb-patches/2015-03/msg00060.html
The record-btrace target can hit an assertion here:
Breakpoint 1, record_btrace_fetch_registers (ops=0x974bfc0 <record_btrace_ops>,
regcache=0x9a0a798, regno=8) at gdb/record-btrace.c:1202
1202 gdb_assert (tp != NULL);
(gdb) p regcache->ptid
$3 = {pid = 23856, lwp = 0, tid = 0}
The problem is that the linux-nat layer converts the ptid to a
single-process ptid before passing the request down to the inf-ptrace
layer, which loses information, and then record-btrace can't find the
corresponding thread in GDB's thread list:
(gdb) bt
#0 record_btrace_fetch_registers (ops=0x974bfc0 <record_btrace_ops>, regcache=0x9a0a798, regno=8)
at gdb/record-btrace.c:1202
#1 0x083f4ee2 in delegate_fetch_registers (self=0x974bfc0 <record_btrace_ops>, arg1=0x9a0a798,
arg2=8) at gdb/target-delegates.c:149
#2 0x08406562 in target_fetch_registers (regcache=0x9a0a798, regno=8)
at gdb/target.c:3279
#3 0x08355255 in regcache_raw_read (regcache=0x9a0a798, regnum=8,
buf=0xbfffe6c0 "¨\003\222\tÀ8kIøæÿ¿HO5\b\035]")
at gdb/regcache.c:643
#4 0x083558a7 in regcache_cooked_read (regcache=0x9a0a798, regnum=8,
buf=0xbfffe6c0 "¨\003\222\tÀ8kIøæÿ¿HO5\b\035]")
at gdb/regcache.c:734
#5 0x08355de3 in regcache_cooked_read_unsigned (regcache=0x9a0a798, regnum=8, val=0xbfffe738)
at gdb/regcache.c:838
#6 0x0827a106 in i386_linux_resume (ops=0x9737ca0 <linux_ops_saved>, ptid=..., step=1,
signal=GDB_SIGNAL_0) at gdb/i386-linux-nat.c:670
#7 0x08280c12 in linux_resume_one_lwp (lp=0x9a0a5b8, step=1, signo=GDB_SIGNAL_0)
at gdb/linux-nat.c:1529
#8 0x08281281 in linux_nat_resume (ops=0x98da608, ptid=..., step=1, signo=GDB_SIGNAL_0)
at gdb/linux-nat.c:1708
#9 0x0850738e in record_btrace_resume (ops=0x98da608, ptid=..., step=1, signal=GDB_SIGNAL_0)
at gdb/record-btrace.c:1760
...
The fix is just to not lose information, and let the intact ptid reach
record-btrace.c.
Tested on x86-64 Fedora 20, -m32.
gdb/ChangeLog:
2015-03-03 Pedro Alves <palves@redhat.com>
* i386-linux-nat.c (i386_linux_resume): Get the ptrace PID out of
the lwp field of ptid. Pass the full ptid to get_thread_regcache.
* inf-ptrace.c (get_ptrace_pid): New function.
(inf_ptrace_resume): Use it.
* linux-nat.c (linux_resume_one_lwp): Pass the LWP's ptid ummodified
to the lower layer.
TL;DR - GDB can hang if something refreshes the thread list out of the
target while the target is running. GDB hangs inside td_ta_thr_iter.
The fix is to not use that libthread_db function anymore.
Long version:
Running the testsuite against my all-stop-on-top-of-non-stop series is
still exposing latent non-stop bugs.
I was originally seeing this with the multi-create.exp test, back when
we were still using libthread_db thread event breakpoints. The
all-stop-on-top-of-non-stop series forces a thread list refresh each
time GDB needs to start stepping over a breakpoint (to pause all
threads). That test hits the thread event breakpoint often, resulting
in a bunch of step-over operations, thus a bunch of thread list
refreshes while some threads in the target are running.
The commit adds a real non-stop mode test that triggers the issue,
based on multi-create.exp, that does an explicit "info threads" when a
breakpoint is hit. IOW, it does the same things the as-ns series was
doing when testing multi-create.exp.
The bug is a race, so it unfortunately takes several runs for the test
to trigger it. In fact, even when setting the test running in a loop,
it sometimes takes several minutes for it to trigger for me.
The race is related to libthread_db's td_ta_thr_iter. This is
libthread_db's entry point for walking the thread list of the
inferior.
Sometimes, when GDB refreshes the thread list from the target,
libthread_db's td_ta_thr_iter can somehow see glibc's thread list as a
cycle, and get stuck in an infinite loop.
The issue is that when a thread exits, its thread control structure in
glibc is moved from a "used" list to a "cache" list. These lists are
simply circular linked lists where the "next/prev" pointers are
embedded in the thread control structure itself. The "next" pointer
of the last element of the list points back to the list's sentinel
"head". There's only one set of "next/prev" pointers for both lists;
thus a thread can only be in one of the lists at a time, not in both
simultaneously.
So when thread C exits, simplifying, the following happens. A-C are
threads. stack_used and stack_cache are the list's heads.
Before:
stack_used -> A -> B -> C -> (&stack_used)
stack_cache -> (&stack_cache)
After:
stack_used -> A -> B -> (&stack_used)
stack_cache -> C -> (&stack_cache)
td_ta_thr_iter starts by iterating at the list's head's next, and
iterates until it sees a thread whose next pointer points to the
list's head again. Thus in the before case above, C's next points to
stack_used, indicating end of list. In the same case, the stack_cache
list is empty.
For each thread being iterated, td_ta_thr_iter reads the whole thread
object out of the inferior. This includes the thread's "next"
pointer.
In the scenario above, it may happen that td_ta_thr_iter is iterating
thread B and has already read B's thread structure just before thread
C exits and its control structure moves to the cached list.
Now, recall that td_ta_thr_iter is running in the context of GDB, and
there's no locking between GDB and the inferior. From it's local copy
of B, td_ta_thr_iter believes that the next thread after B is thread
C, so it happilly continues iterating to C, a thread that has already
exited, and is now in the stack cache list.
After iterating C, td_ta_thr_iter finds the stack_cache head, which
because it is not stack_used, td_ta_thr_iter assumes it's just another
thread. After this, unless the reverse race triggers, GDB gets stuck
in td_ta_thr_iter forever walking the stack_cache list, as no thread
in thatlist has a next pointer that points back to stack_used (the
terminating condition).
Before fully understanding the issue, I tried adding cycle detection
to GDB's td_ta_thr_iter callback. However, td_ta_thr_iter skips
calling the callback in some cases, which means that it's possible
that the callback isn't called at all, making it impossible for GDB to
break the loop. I did manage to get GDB stuck in that state more than
once.
Fortunately, we can avoid the issue altogether. We don't really need
td_ta_thr_iter for live debugging nowadays, given PTRACE_EVENT_CLONE.
We already know how to map and lwp id to a thread id without iterating
(thread_from_lwp), so use that more.
gdb/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait): Call
thread_db_notice_clone whenever a new clone LWP is detected.
(linux_stop_and_wait_all_lwps, linux_unstop_all_lwps): New
functions.
* linux-nat.h (thread_db_attach_lwp): Delete declaration.
(thread_db_notice_clone, linux_stop_and_wait_all_lwps)
(linux_unstop_all_lwps): Declare.
* linux-thread-db.c (struct thread_get_info_inout): Delete.
(thread_get_info_callback): Delete.
(thread_from_lwp): Use td_thr_get_info and record_thread.
(thread_db_attach_lwp): Delete.
(thread_db_notice_clone): New function.
(try_thread_db_load_1): If /proc is mounted and shows the
process'es task list, walk over all LWPs and call thread_from_lwp
instead of relying on td_ta_thr_iter.
(attach_thread): Don't call check_thread_signals here. Split the
tail part of the function (which adds the thread to the core GDB
thread list) to ...
(record_thread): ... this function. Call check_thread_signals
here.
(thread_db_wait): Don't call thread_db_find_new_threads_1. Always
call thread_from_lwp.
(thread_db_update_thread_list): Rename to ...
(thread_db_update_thread_list_org): ... this.
(thread_db_update_thread_list): New function.
(thread_db_find_thread_from_tid): Delete.
(thread_db_get_ada_task_ptid): Simplify.
* nat/linux-procfs.c: Include <sys/stat.h>.
(linux_proc_task_list_dir_exists): New function.
* nat/linux-procfs.h (linux_proc_task_list_dir_exists): Declare.
gdb/gdbserver/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* thread-db.c: Include "nat/linux-procfs.h".
(thread_db_init): Skip listing new threads if the kernel supports
PTRACE_EVENT_CLONE and /proc/PID/task/ is accessible.
gdb/testsuite/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* gdb.threads/multi-create-ns-info-thr.exp: New file.
This function has a few latent bugs that are triggered by a non-stop
mode test that will be added in a subsequent patch.
First, as described in the function's intro comment, the function is
supposed to return 1 if we're already auto attached to the thread, but
haven't processed the PTRACE_EVENT_CLONE event of its parent thread
yet.
Then, we may find that we're trying to attach to a clone child that
hasn't yet stopped for its initial stop, and therefore 'waitpid(...,
WNOHANG)' returns 0. In that case, we're currently adding the LWP to
the stopped_pids list, which results in linux_handle_extended_wait
skipping the waitpid call on the child, and thus confusing things
later on when the child eventually reports the stop.
Then, the tail end of lin_lwp_attach_lwp always sets the
last_resume_kind of the LWP to resume_stop, which is wrong given that
the user may be doing "info threads" while some threads are running.
And then, the else branch of lin_lwp_attach_lwp always sets the
stopped flag of the LWP. This branch is reached if the LWP is the
main LWP, which may well be running at this point (to it's wrong to
set its 'stopped' flag).
AFAICS, there's no reason anymore for special-casing the main/leader
LWP here:
- For the "attach" case, linux_nat_attach already adds the main LWP to
the lwp list, and sets its 'stopped' flag.
- For the "run" case, after linux_nat_create_inferior, end up in
linux_nat_wait_1 here:
/* The first time we get here after starting a new inferior, we may
not have added it to the LWP list yet - this is the earliest
moment at which we know its PID. */
if (ptid_is_pid (inferior_ptid))
{
/* Upgrade the main thread's ptid. */
thread_change_ptid (inferior_ptid,
ptid_build (ptid_get_pid (inferior_ptid),
ptid_get_pid (inferior_ptid), 0));
lp = add_initial_lwp (inferior_ptid);
lp->resumed = 1;
}
... which adds the LWP to the LWP list already, before
lin_lwp_attach_lwp can ever be reached.
gdb/ChangeLog:
2015-02-20 Pedro Alves <palves@redhat.com>
* linux-nat.c (lin_lwp_attach_lwp): No longer special case the
main LWP. Handle the case of waitpid returning 0 if we're already
attached to the LWP. Don't set the LWP's last_resume_kind to
resume_stop if we already knew about the LWP.
(linux_nat_filter_event): Add debug logs.
When gdb creates a dummy frame to execute a function in the inferior,
the process may generate a SIGSEGV, SIGTRAP or SIGILL because the stack
is non executable. If the signal handler set in gdb has option print
or stop enabled for these signals gdb handles this correctly.
However, in the case of noprint and nostop the signal is short-circuited
and the inferior process is sent the signal directly. This causes the
inferior to crash because of gdb.
This patch adds a check for SIGSEGV, SIGTRAP or SIGILL so that these
signals are sent to gdb rather than short-circuited in the inferior.
gdb then handles them properly and the inferior process does not
crash.
This patch also fixes the same behavior in gdbserver.
Also added a small testcase to test the issue called catch-gdb-caused-signals.
This applies to Linux only, tested on Linux.
gdb/ChangeLog:
PR breakpoints/16812
* linux-nat.c (linux_nat_filter_event): Report SIGTRAP,SIGILL,SIGSEGV.
* nat/linux-ptrace.c (linux_wstatus_maybe_breakpoint): Add.
* nat/linux-ptrace.h: Add linux_wstatus_maybe_breakpoint.
gdb/gdbserver/ChangeLog:
PR breakpoints/16812
* linux-low.c (wstatus_maybe_breakpoint): Remove.
(linux_low_filter_event): Update wstatus_maybe_breakpoint name.
(linux_wait_1): Report SIGTRAP,SIGILL,SIGSEGV.
gdb/testsuite/ChangeLog:
PR breakpoints/16812
* gdb.base/catch-gdb-caused-signals.c: New file.
* gdb.base/catch-gdb-caused-signals.exp: New file.
Since the starvation avoidance series
(https://sourceware.org/ml/gdb-patches/2014-12/msg00631.html), both
GDB and GDBserver pull all events out of ptrace before deciding which
event to process.
There's one problem with that though. Because we resume new threads
immediately when we see a PTRACE_EVENT_CLONE event, if the program
constantly spawns threads fast enough, new threads can spawn threads
faster we can pull events out of the kernel, and thus we'd get stuck
in an infinite loop, never returning any event to the core to process.
I occasionally see this happen with the
attach-many-short-lived-threads.exp test against gdbserver.
The fix is to delay resuming new threads until we've pulled out all
events out of the kernel.
On native, we already have the resume_stopped_resumed_lwps function
that knows to resume LWPs that are stopped with no event to report to
the core. So the patch just adds another use. GDBserver didn't have
the equivalent yet, so the patch adds one.
Tested on x86_64 Fedora 20, native and gdbserver (remote and
extended-remote).
gdb/gdbserver/ChangeLog:
2015-02-04 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Don't resume LWPs here.
(resume_stopped_resumed_lwps): New function.
(linux_wait_for_event_filtered): Use it.
gdb/ChangeLog:
2015-02-04 Pedro Alves <palves@redhat.com>
* linux-nat.c (handle_extended_wait): Don't resume LWPs here.
(wait_lwp): Don't call wait_lwp if linux_handle_extended_wait
returns true.
(resume_stopped_resumed_lwps): Don't check whether the thread is
marked as executing.
(linux_nat_wait_1): Use resume_stopped_resumed_lwps.
In all these cases we're interested in whether the target is currently
async, with its event sources installed in the event loop, not whether
it can async if needed. Also, I'm not seeing the point of the
target_async call from within linux_nat_wait. That's normally done on
resume instead, which this target already does.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2015-02-03 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_child_follow_fork, linux_nat_wait_1): Use
target_is_async_p instead of target_can_async.
(linux_nat_wait): Use target_is_async_p instead of
target_can_async. Don't enable async here.
* remote.c (interrupt_query, remote_wait, putpkt_binary): Use
target_is_async_p instead of target_can_async.
linux_nat_is_async_p currently always returns true, even when the
target is _not_ async. That confuses
gdb_readline_wrapper/gdb_readline_wrapper_cleanup, which
force-disables target-async while the secondary prompt is active. As
a result, when gdb_readline_wrapper returns, the target is left async,
even through it was sync to begin with.
That can result in weird bugs, like the one the test added by this
commit exposes.
Ref: https://sourceware.org/ml/gdb-patches/2015-01/msg00592.html
gdb/ChangeLog:
2015-01-23 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_is_async_p): New macro.
(linux_nat_is_async_p):
(linux_nat_terminal_inferior): Check whether the target can async
instead of whether it is already async.
(linux_nat_terminal_ours): Don't check whether the target is
async.
(linux_async_pipe): Use linux_is_async_p.
gdb/testsuite/ChangeLog:
2015-01-23 Pedro Alves <palves@redhat.com>
* gdb.threads/continue-pending-after-query.c: New file.
* gdb.threads/continue-pending-after-query.exp: New file.
This patch moves the shared code present on
gdb/linux-nat.c:linux_nat_create_inferior and
gdb/gdbserver/linux-low.c:linux_create_inferior to
nat/linux-personality.c. This code is responsible for disabling
address space randomization based on user setting, and using
<sys/personality.h> to do that. I decided to put the prototype of the
maybe_disable_address_space_randomization on nat/linux-osdata.h
because it seemed the best place to put it.
I regression-tested this patch on Fedora 20 x86_64, and found no
regressions.
gdb/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (HFILES_NO_SRCDIR): Add nat/linux-personality.h.
(linux-personality.o): New rule.
* common/common-defs.h: Include <stdint.h>.
* config/aarch64/linux.mh (NATDEPFILES): Include
linux-personality.o.
* config/alpha/alpha-linux.mh (NATDEPFILES): Likewise.
* config/arm/linux.mh (NATDEPFILES): Likewise.
* config/i386/linux64.mh (NATDEPFILES): Likewise.
* config/i386/linux.mh (NATDEPFILES): Likewise.
* config/ia64/linux.mh (NATDEPFILES): Likewise.
* config/m32r/linux.mh (NATDEPFILES): Likewise.
* config/m68k/linux.mh (NATDEPFILES): Likewise.
* config/mips/linux.mh (NATDEPFILES): Likewise.
* config/pa/linux.mh (NATDEPFILES): Likewise.
* config/powerpc/linux.mh (NATDEPFILES): Likewise.
* config/powerpc/ppc64-linux.mh (NATDEPFILES): Likewise.
* config/powerpc/spu-linux.mh (NATDEPFILES): Likewise.
* config/s390/linux.mh (NATDEPFILES): Likewise.
* config/sparc/linux64.mh (NATDEPFILES): Likewise.
* config/sparc/linux.mh (NATDEPFILES): Likewise.
* config/tilegx/linux.mh (NATDEPFILES): Likewise.
* config/xtensa/linux.mh (NATDEPFILES): Likewise.
* defs.h: Remove #include <stdint.h> (moved to
common/common-defs.h).
* linux-nat.c: Include nat/linux-personality.h. Remove #include
<sys/personality.h>; do not define ADDR_NO_RANDOMIZE (moved to
nat/linux-personality.c).
(linux_nat_create_inferior): Remove code to disable address space
randomization (moved to nat/linux-personality.c). Create cleanup
to disable address space randomization.
* nat/linux-personality.c: New file.
* nat/linux-personality.h: Likewise.
gdb/gdbserver/ChangeLog
2015-01-15 Sergio Durigan Junior <sergiodj@redhat.com>
* Makefile.in (SFILES): Add linux-personality.c.
(linux-personality.o): New rule.
* configure.srv (srv_linux_obj): Add linux-personality.o to the
list of objects to be built.
* linux-low.c: Include nat/linux-personality.h.
(linux_create_inferior): Remove code to disable address space
randomization (moved to ../nat/linux-personality.c). Create
cleanup to disable address space randomization.
Running the testsuite with a series that reimplements user-visible
all-stop behavior on top of a target running in non-stop mode revealed
problems related to event starvation avoidance.
For example, I see
gdb.threads/signal-while-stepping-over-bp-other-thread.exp failing.
What happens is that GDB core never gets to see the signal event. It
ends up processing the events for the same threads over an over,
because Linux's waitpid(-1, ...) returns that first task in the task
list that has an event, starving threads on the tail of the task list.
So I wrote a non-stop mode test originally inspired by
signal-while-stepping-over-bp-other-thread.exp, to stress this
independently of all-stop on top of non-stop. Fixing it required the
changes described below. The test will be added in a following
commit.
1) linux-nat.c has code in place that picks an event LWP at random out
of all that have had events. This is because on the kernel side,
"waitpid(-1, ...)" just walks the task list linearly looking for the
first that had an event. But, this code is currently only used in
all-stop mode. So with a multi-threaded program that has multiple
events triggering debug events in parallel, GDB ends up starving some
threads.
To make the event randomization work in non-stop mode too, the patch
makes us pull out all the already pending events on the kernel side,
with waitpid, before deciding which LWP to report to the core.
There's some code in linux_wait that takes care of leaving events
pending if they were for LWPs the caller is not interested in. The
patch moves that to linux_nat_filter_event, so that we only have one
place that leaves events pending. With that in place, conceptually,
the flow is simpler and more normalized:
#1 - walk the LWP list looking for an LWP with a pending event to report.
#2 - if no pending event, pull events out of the kernel, and store
them in the LWP structures as pending.
#3- goto #1.
2) Then, currently the event randomization code only considers SIGTRAP
(or trap-like) events. That means that if e.g., have have multiple
threads stepping in parallel that hit a breakpoint that needs stepping
over, and one gets a signal, the signal may end up never getting
processed, because GDB will always be giving priority to the SIGTRAPs.
The patch fixes this by making the randomization code consider all
kinds of pending events.
3) If multiple threads hit a breakpoint, we report one of those, and
"cancel" the others. Cancelling means decrementing the PC, and
discarding the event. If the next time the LWP is resumed the
breakpoint is still installed, the LWP should hit it again, and we'll
report the hit then. The problem I found is that this delays threads
from advancing too much, with the kernel potentially ending up
scheduling the same threads over and over, and others not advancing.
So the patch switches away from cancelling the breakpoints, and
instead remembering that the LWP had stopped for a breakpoint. If on
resume the breakpoint is still installed, we report it. If it's no
longer installed, we discard the pending event then. This is actually
how GDBserver used to handle this before d50171e4 (Teach linux
gdbserver to step-over-breakpoints), but with the difference that back
then we'd delay adjusting the PC until resuming, which made it so that
"info threads" could wrongly see threads with unadjusted PCs.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* breakpoint.c (hardware_breakpoint_inserted_here_p): New
function.
* breakpoint.h (hardware_breakpoint_inserted_here_p): New
declaration.
* linux-nat.c (linux_nat_status_is_event): Move higher up in file.
(linux_resume_one_lwp): Store the thread's PC. Adjust to clear
stop_reason.
(check_stopped_by_watchpoint): New function.
(save_sigtrap): Reimplement.
(linux_nat_stopped_by_watchpoint): Adjust.
(linux_nat_lp_status_is_event): Delete.
(stop_wait_callback): Only call save_sigtrap after storing the
pending status.
(status_callback): If the thread had been stopped for a breakpoint
that has since been removed, discard the event and resume the LWP.
(count_events_callback, select_event_lwp_callback): Use
lwp_status_pending_p instead of linux_nat_lp_status_is_event.
(cancel_breakpoint): Rename to ...
(check_stopped_by_breakpoint): ... this. Record whether the LWP
stopped for a software breakpoint or hardware breakpoint.
(select_event_lwp): Only give preference to the stepping LWP in
all-stop mode. Adjust comments.
(stop_and_resume_callback): Remove references to new_pending_p.
(linux_nat_filter_event): Likewise. Leave exit events of the
leader thread pending here. Handle signal short circuiting here.
Only call save_sigtrap after storing the pending waitstatus.
(linux_nat_wait_1): Remove 'retry' label. Remove references to
new_pending. Don't handle leaving events the caller is not
interested in pending here, nor handle signal short-circuiting
here. Also give equal priority to all LWPs that have had events
in non-stop mode. If reporting a software breakpoint event,
unadjust the LWP's PC.
* linux-nat.h (enum lwp_stop_reason): New.
(struct lwp_info) <stop_pc>: New field.
(struct lwp_info) <stopped_by_watchpoint>: Delete field.
(struct lwp_info) <stop_reason>: New field.
* x86-linux-nat.c (x86_linux_prepare_to_resume): Adjust.
A subsequent patch will make the Linux backend's target_wait method
pull all events out of the kernel (with waitpid) and store them as
pending status in the LWP structure if no pending status was already
available. Then, the backend goes over the pending statuses and pick
one to report to the core.
With that, the existing thread-execl.exp test exposes a bug, like:
(gdb) set scheduler-locking on
(gdb) PASS: gdb.threads/thread-execl.exp: schedlock on: set scheduler-locking on
next
FAIL: gdb.threads/thread-execl.exp: schedlock on: get to main in new image (timeout)
Recall that when the non-leader thread execs, all threads in the
process die, the execing thread changes its pid to the tgid, and then
waitpid returns an exec event to the tgid. If GDB didn't resume the
leader LWP, then GDB sees an event for an LWP that was supposedly
stopped, and thus not marked as resumed. Because the code that picks
a pending event to report to the core ignores not-resumed LWPs:
/* Return non-zero if LP has a wait status pending. */
static int
status_callback (struct lwp_info *lp, void *data)
{
/* Only report a pending wait status if we pretend that this has
indeed been resumed. */
if (!lp->resumed)
return 0;
the event ends up pending forever, thus the timeout.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_handle_extended_wait) <PTRACE_EVENT_EXEC>:
Set the LWP's 'resumed' flag.
Whenever we resume an LWP, we must clear a few flags and flush the
LWP's register cache. We actually currently flush the register cache
of all LWPs, but that's unnecessary. This patch makes us flush the
register cache of only the LWP that is resumed. Instead of open
coding all that in many places, we use a helper function.
Likewise, we have two fields in the LWP structure where a pending
status may be recorded. Add a helper predicate that checks both and
use it throughout instead of open coding the checks.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (linux_resume_one_lwp): New function.
(resume_lwp): Use lwp_status_pending_p and linux_resume_one_lwp.
(linux_nat_resume): Use lwp_status_pending_p and
linux_resume_one_lwp.
(linux_handle_syscall_trap): Use linux_resume_one_lwp.
(linux_handle_extended_wait): Use linux_resume_one_lwp.
(status_callback, running_callback): Use lwp_status_pending_p.
(lwp_status_pending_p): New function.
(stop_and_resume_callback): Use lwp_status_pending_p.
(linux_nat_filter_event): Use linux_resume_one_lwp.
(linux_nat_wait_1): Always use status_callback to look for an LWP
with a pending status. Use linux_resume_one_lwp.
(resume_stopped_resumed_lwps): Use lwp_status_pending_p and
linux_resume_one_lwp.
I wrote a test that attaches to a program that constantly spawns
short-lived threads, which exposed several issues. This is one of
them.
On GNU/Linux, attaching to a multi-threaded program sometimes prints
out warnings like:
...
[New LWP 20700]
warning: unable to open /proc file '/proc/-1/status'
[New LWP 20850]
[New LWP 21019]
...
That happens because when a thread exits, and is joined, glibc does:
nptl/pthread_join.c:
pthread_join ()
{
...
if (__glibc_likely (result == 0))
{
/* We mark the thread as terminated and as joined. */
pd->tid = -1;
...
/* Free the TCB. */
__free_tcb (pd);
}
So if we attach or interrupt the program (which does an implicit "info
threads") at just the right (or rather, wrong) time, we can find and
return threads in the libthread_db/pthreads thread list with kernel
thread ID -1. I've filed glibc PR nptl/17707 for this. You'll find
more info there.
This patch handles this as a special case in GDB.
This is actually more than just a cosmetic issue. lin_lwp_attach_lwp
will think that this -1 is an LWP we're not attached to yet, and after
failing to attach will try to check we were already attached to the
process, using a waitpid call, which in this case ends up being
"waitpid (-1, ...", which obviously results in GDB potentially
discarding an event when it shouldn't...
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/gdbserver/
2015-01-09 Pedro Alves <palves@redhat.com>
* thread-db.c (find_new_threads_callback): Ignore thread if the
kernel thread ID is -1.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (lin_lwp_attach_lwp): Assert that the lwp id we're
about to wait for is > 0.
* linux-thread-db.c (find_new_threads_callback): Ignore thread if
the kernel thread ID is -1.
... instead of relying on libthread_db.
I wrote a test that attaches to a program that constantly spawns
short-lived threads, which exposed several issues. This is one of
them.
On Linux, we need to attach to all threads of a process (thread group)
individually. We currently rely on libthread_db to list the threads,
but that is problematic, because libthread_db relies on reading data
structures out of the inferior (which may well be corrupted). If
threads are being created or exiting just while we try to attach, we
may trip on inconsistencies in the inferior's thread list. To work
around that, when we see a seemingly corrupt list, we currently retry
a few times:
static void
thread_db_find_new_threads_2 (ptid_t ptid, int until_no_new)
{
...
if (until_no_new)
{
/* Require 4 successive iterations which do not find any new threads.
The 4 is a heuristic: there is an inherent race here, and I have
seen that 2 iterations in a row are not always sufficient to
"capture" all threads. */
...
That heuristic may well fail, and when it does, we end up with threads
in the program that aren't under GDB's control. That's obviously bad
and results in quite mistifying failures, like e.g., the process dying
for seeminly no reason when a thread that wasn't attached trips on a
breakpoint.
There's really no reason to rely on libthread_db for this nowadays
when we have /proc mounted. In that case, which is the usual case, we
can list the LWPs from /proc/PID/task/. In fact, GDBserver is already
doing this. The patch factors out that code that knows to walk the
task/ directory out of GDBserver, and makes GDB use it too.
Like GDBserver, the patch makes GDB attach to LWPs and _not_ wait for
them to stop immediately. Instead, we just tag the LWP as having an
expected stop. Because we can only set the ptrace options when the
thread stops, we need a new flag in the lwp structure to keep track of
whether we've already set the ptrace options, just like in GDBserver.
Note that nothing issues any ptrace command to the threads between the
PTRACE_ATTACH and the stop, so this is safe (unlike one scenario
described in gdbserver's linux-low.c).
When we attach to a program that has threads exiting while we attach,
it's easy to race with a thread just exiting as we try to attach to
it, like:
#1 - get current list of threads
#2 - attach to each listed thread
#3 - ooops, attach failed, thread is already gone
As this is pretty normal, we shouldn't be issuing a scary warning in
step #3.
When #3 happens, PTRACE_ATTACH usually fails with ESRCH, but sometimes
we'll see EPERM as well. That happens when the kernel still has the
thread in its task list, but the thread is marked as dead.
Unfortunately, EPERM is ambiguous and we'll get it also on other
scenarios where the thread isn't dead, and in those cases, it's useful
to get a warning. To distiguish the cases, when we get an EPERM
failure, we open /proc/PID/status, and check the thread's state -- if
the /proc file no longer exists, or the state is "Z (Zombie)" or "X
(Dead)", we ignore the EPERM error silently; otherwise, we'll warn.
Unfortunately, there seems to be a kernel race here. Sometimes I get
EPERM, and then the /proc state still indicates "R (Running)"... If
we wait a bit and retry, we do end up seeing X or Z state, or get an
ESRCH. I thought of making GDB retry the attach a few times, but even
with a 500ms wait and 4 retries, I still see the warning sometimes. I
haven't been able to identify the kernel path that causes this yet,
but in any case, it looks like a kernel bug to me. As this just
results failure to suppress a warning that we've been printing since
about forever anyway, I'm just making the test cope with it, and issue
an XFAIL.
gdb/gdbserver/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_attach_fail_reason_string): Move to
nat/linux-ptrace.c, and rename.
(linux_attach_lwp): Update comment.
(attach_proc_task_lwp_callback): New function.
(linux_attach): Adjust to rename and use
linux_proc_attach_tgid_threads.
(linux_attach_fail_reason_string): Delete declaration.
gdb/
2015-01-09 Pedro Alves <palves@redhat.com>
* linux-nat.c (attach_proc_task_lwp_callback): New function.
(linux_nat_attach): Use linux_proc_attach_tgid_threads.
(wait_lwp, linux_nat_filter_event): If not set yet, set the lwp's
ptrace option flags.
* linux-nat.h (struct lwp_info) <must_set_ptrace_flags>: New
field.
* nat/linux-procfs.c: Include <dirent.h>.
(linux_proc_get_int): New parameter "warn". Handle it.
(linux_proc_get_tgid): Adjust.
(linux_proc_get_tracerpid): Rename to ...
(linux_proc_get_tracerpid_nowarn): ... this.
(linux_proc_pid_get_state): New function, factored out from
(linux_proc_pid_has_state): ... this. Add new parameter "warn"
and handle it.
(linux_proc_pid_is_gone): New function.
(linux_proc_pid_is_stopped): Adjust.
(linux_proc_pid_is_zombie_maybe_warn)
(linux_proc_pid_is_zombie_nowarn): New functions.
(linux_proc_pid_is_zombie): Use
linux_proc_pid_is_zombie_maybe_warn.
(linux_proc_attach_tgid_threads): New function.
* nat/linux-procfs.h (linux_proc_get_tgid): Update comment.
(linux_proc_get_tracerpid): Rename to ...
(linux_proc_get_tracerpid_nowarn): ... this, and update comment.
(linux_proc_pid_is_gone): New declaration.
(linux_proc_pid_is_zombie): Update comment.
(linux_proc_pid_is_zombie_nowarn): New declaration.
(linux_proc_attach_lwp_func): New typedef.
(linux_proc_attach_tgid_threads): New declaration.
* nat/linux-ptrace.c (linux_ptrace_attach_fail_reason): Adjust to
use nowarn functions.
(linux_ptrace_attach_fail_reason_string): Move here from
gdbserver/linux-low.c and rename.
(ptrace_supports_feature): If the current ptrace options are not
known yet, check them now, instead of asserting.
* nat/linux-ptrace.h (linux_ptrace_attach_fail_reason_string):
Declare.
This patch enhances GDB on GNU/Linux systems in the situation where
we are debugging an inferior that was created from GDB (as opposed
to attached to), by asking the kernel to kill the inferior if GDB
terminates without doing it itself.
This would typically happen when GDB encounters a problem and
crashes, or when it gets killed by an external process. This can
be observed by starting a program under GDB, and then killing
GDB with signal 9. After GDB is killed, the inferior still remains.
This patch also fixes GDBserver similarly.
This fix is conditional on the kernel supporting the PTRACE_O_EXITKILL
feature. On older kernels, the behavior remains unchanged.
gdb/ChangeLog:
* nat/linux-ptrace.h (PTRACE_O_EXITKILL): Define if not
already defined.
(linux_enable_event_reporting): Add parameter "attached".
* nat/linux-ptrace.c (linux_test_for_exitkill): New forward
declaration. New function.
(linux_check_ptrace_features): Add linux_test_for_exitkill call.
(linux_enable_event_reporting): Add new parameter "attached".
Do not call ptrace with the PTRACE_O_EXITKILL if ATTACHED is
nonzero.
* linux-nat.c (linux_init_ptrace): Add parameter "attached".
Use it. Update function description.
(linux_child_post_attach, linux_child_post_startup_inferior):
Update call to linux_enable_event_reporting.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_low_filter_event): Update call to
linux_enable_event_reporting following the addition of
a new parameter to that function.
Tested on x86_64-linux, native and native-gdbserver.
I also verified by hand that the inferior gets killed when killing
GDB in the "run" case, while the inferior remains in the "attach"
case. Same for GDBserver.
This patch introduces find_inferior_ptid to replace the common idiom
find_inferior_pid (ptid_get_pid (...));
It replaces all the instances of that idiom that I found with the new
function.
No significant changes before/after the patch in the regression suite
on amd64 linux.
gdb/ChangeLog:
* inferior.c (find_inferior_ptid): New function.
* inferior.h (find_inferior_ptid): New declaration.
* ada-tasks.c (ada_get_task_number): Use find_inferior_ptid.
* corelow.c (core_pid_to_str): Same.
* darwin-nat.c (darwin_resume): Same.
* infrun.c (fetch_inferior_event): Same.
(get_inferior_stop_soon): Same.
(handle_inferior_event): Same.
(handle_signal_stop): Same.
* linux-nat.c (resume_lwp): Same.
(stop_wait_callback): Same.
* mi/mi-interp.c (mi_new_thread): Same.
(mi_thread_exit): Same.
* proc-service.c (ps_pglobal_lookup): Same.
* record-btrace.c (record_btrace_step_thread): Same.
* remote-sim.c (gdbsim_close_inferior): Same.
(gdbsim_resume): Same.
(gdbsim_stop): Same.
* sol2-tdep.c (sol2_core_pid_to_str): Same.
* target.c (memory_xfer_partial_1): Same.
(default_thread_address_space): Same.
* thread.c (thread_change_ptid): Same.
(switch_to_thread): Same.
(do_restore_current_thread_cleanup): Same.
This patch reorganizes the code that implements follow-fork and
detach-on-fork in preparation for implementation of those features for the
extended-remote target. The function linux-nat.c:linux_child_follow_fork
contained target-independent code mixed in with target-dependent code. The
target-independent pieces need to be accessible for the host-side
implementation of follow-fork for extended-remote Linux targets.
The changes are fairly mechanical. A new routine, follow_fork_inferior,
is implemented in infrun.c, containing those parts of
linux_child_follow_fork that manage inferiors and the inferior list. The
parts of linux_child_follow_fork that deal with LWPs and target-specifics
were left in-place. Although the order of some operations was changed, the
resulting functionality was not.
Modifications were made to the other native target follow-fork functions,
inf_ttrace_follow_fork and inf_ptrace_follow_fork, that should allow them
to work with follow_fork_inferior. Some other adjustments were necessary
in inf-ttrace.c. The changes to inf-ttrace.c and inf-ptrace.c were not
tested.
gdb/ChangeLog:
* inf-ptrace.c (inf_ptrace_follow_fork): Remove target-independent
code so as to work with follow_fork_inferior.
* inf-ttrace.c (inf_ttrace_follow_fork): Ditto.
(inf_ttrace_create_inferior): Remove reference to
inf_ttrace_vfork_ppid.
(inf_ttrace_attach): Ditto.
(inf_ttrace_detach): Ditto.
(inf_ttrace_kill): Use current_inferior instead of
inf_ttrace_vfork_ppid.
(inf_ttrace_wait): Eliminate use of inf_ttrace_vfork_ppid, report
TARGET_WAITKIND_VFORK_DONE event, delete HACK that switched the
inferior away from the parent.
* infrun.c (follow_fork): Call follow_fork_inferior instead of
target_follow_fork.
(follow_fork_inferior): New function.
(follow_inferior_reset_breakpoints): Make function static.
* infrun.h (follow_inferior_reset_breakpoints): Remove declaration.
* linux-nat.c (linux_child_follow_fork): Move target-independent
code to infrun.c:follow_fork_inferior.
Now that all Linux targets use the regset iterator, the fall back to
the deprecated target method is dropped.
gdb/ChangeLog:
* linux-nat.c (linux_nat_collect_thread_registers): Remove.
(linux_nat_make_corefile_notes): Remove.
(linux_target_install_ops): Do not set target method
'make_corefile_notes'.
* linux-tdep.c (struct linux_corefile_thread_data)<collect>:
Remove field.
(linux_corefile_thread_callback): Instead of args->collect, call
linux_collect_thread_registers.
(linux_make_corefile_notes): Remove 'collect' parameter. Return
NULL unless there is a regset iterator.
(linux_make_corefile_notes_1): Remove.
(linux_init_abi): Replace reference to linux_make_corefile_notes_1
by linux_make_corefile_notes.
* linux-tdep.h (linux_make_corefile_notes): Remove prototype.
This commit implements functions for identifying and extracting extended
ptrace event information from a Linux wait status. These are just
convenience functions intended to hide the ">> 16" used to extract the
event from the wait status word, replacing the hard-coded shift with a more
descriptive function call. This is preparatory work for implementation of
follow-fork and detach-on-fork for extended-remote linux targets.
gdb/ChangeLog:
* linux-nat.c (linux_handle_extended_wait): Call
linux_ptrace_get_extended_event.
(wait_lwp): Call linux_is_extended_waitstatus.
(linux_nat_filter_event): Call linux_ptrace_get_extended_event
and linux_is_extended_waitstatus.
* nat/linux-ptrace.c (linux_test_for_tracefork): Call
linux_ptrace_get_extended_event.
(linux_ptrace_get_extended_event): New function.
(linux_is_extended_waitstatus): New function.
* nat/linux-ptrace.h (linux_ptrace_get_extended_event)
(linux_is_extended_waitstatus): New declarations.
gdb/gdbserver/ChangeLog:
* linux-low.c (handle_extended_wait): Call
linux_ptrace_get_extended_event.
(get_stop_pc, get_detach_signal, linux_low_filter_event): Call
linux_is_extended_waitstatus.
---
This is an obvious replacement of "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...", which is the standard to use in
these cases.
gdb/ChangeLog:
2014-09-16 Sergio Durigan Junior <sergiodj@redhat.com>
PR cli/7233
* linux-nat.c (linux_nat_wait_1): Replace "fprintf (stderr..." by
"fprintf_unfiltered (gdb_stdlog...)".
Currently, GDB can pass a signal to the wrong thread in several
different but related scenarios.
E.g., if thread 1 stops for signal SIGFOO, the user switches to thread
2, and then issues "continue", SIGFOO is actually delivered to thread
2, not thread 1. This obviously messes up programs that use
pthread_kill to send signals to specific threads.
This has been a known issue for a long while. Back in 2008 when I
made stop_signal be per-thread (2020b7ab), I kept the behavior -- see
code in 'proceed' being removed -- wanting to come back to it later.
The time has finally come now.
The patch fixes this -- on resumption, intercepted signals are always
delivered to the thread that had intercepted them.
Another example: if thread 1 stops for a breakpoint, the user switches
to thread 2, and then issues "signal SIGFOO", SIGFOO is actually
delivered to thread 1, not thread 2, because 'proceed' first switches
to thread 1 to step over its breakpoint... If the user deletes the
breakpoint before issuing "signal FOO", then the signal is delivered
to thread 2 (the current thread).
"signal SIGFOO" can be used for two things: inject a signal in the
program while the program/thread had stopped for none, bypassing
"handle nopass"; or changing/suppressing a signal the program had
stopped for. These scenarios are really two faces of the same coin,
and GDB can't really guess what the user is trying to do. GDB might
have intercepted signals in more than one thread even (see the new
signal-command-multiple-signals-pending.exp test). At least in the
inject case, it's obviously clear to me that the user means to deliver
the signal to the currently selected thread, so best is to make the
command's behavior consistent and easy to explain.
Then, if the user is trying to suppress/change a signal the program
had stopped for instead of injecting a new signal, but, the user had
changed threads meanwhile, then she will be surprised that with:
(gdb) continue
Thread 1 stopped for signal SIGFOO.
(gdb) thread 2
(gdb) signal SIGBAR
... GDB actually delivers SIGFOO to thread 1, and SIGBAR to thread 2
(with scheduler-locking off, which is the default, because then
"signal" or any other resumption command resumes all threads).
So the patch makes GDB detect that, and ask for confirmation:
(gdb) thread 1
[Switching to thread 1 (Thread 10979)]
(gdb) signal SIGUSR2
Note:
Thread 3 previously stopped with signal SIGUSR2, User defined signal 2.
Thread 2 previously stopped with signal SIGUSR1, User defined signal 1.
Continuing thread 1 (the current thread) with specified signal will
still deliver the signals noted above to their respective threads.
Continue anyway? (y or n)
All these scenarios are covered by the new tests.
Tested on x86_64 Fedora 20, native and gdbserver.
gdb/
2014-07-25 Pedro Alves <palves@redhat.com>
* NEWS: Mention signal passing and "signal" command changes.
* gdbthread.h (struct thread_suspend_state) <stop_signal>: Extend
comment.
* breakpoint.c (until_break_command): Adjust clear_proceed_status
call.
* infcall.c (run_inferior_call): Adjust clear_proceed_status call.
* infcmd.c (proceed_thread_callback, continue_1, step_once)
(jump_command): Adjust clear_proceed_status call.
(signal_command): Warn if other thread that are resumed have
signals that will be delivered. Adjust clear_proceed_status call.
(until_next_command, finish_command)
(proceed_after_attach_callback, attach_command_post_wait)
(attach_command): Adjust clear_proceed_status call.
* infrun.c (proceed_after_vfork_done): Likewise.
(proceed_after_attach_callback): Adjust comment.
(clear_proceed_status_thread): Clear stop_signal if not in pass
state.
(clear_proceed_status_callback): Delete.
(clear_proceed_status): New 'step' parameter. Only clear the
proceed status of threads the command being prepared is about to
resume.
(proceed): If passed in an explicit signal, override stop_signal
with it. Don't pass the last stop signal to the thread we're
resuming.
(init_wait_for_inferior): Adjust clear_proceed_status call.
(switch_back_to_stepped_thread): Clear the signal if it should not
be passed.
* infrun.h (clear_proceed_status): New 'step' parameter.
(user_visible_resume_ptid): Add comment.
* linux-nat.c (linux_nat_resume_callback): Don't check whether the
signal is in pass state.
* remote.c (append_pending_thread_resumptions): Likewise.
* mi/mi-main.c (proceed_thread): Adjust clear_proceed_status call.
gdb/doc/
2014-07-25 Pedro Alves <palves@redhat.com>
Eli Zaretskii <eliz@gnu.org>
* gdb.texinfo (Signaling) <signal command>: Explain what happens
with multi-threaded programs.
gdb/testsuite/
2014-07-25 Pedro Alves <palves@redhat.com>
* gdb.threads/signal-command-handle-nopass.c: New file.
* gdb.threads/signal-command-handle-nopass.exp: New file.
* gdb.threads/signal-command-multiple-signals-pending.c: New file.
* gdb.threads/signal-command-multiple-signals-pending.exp: New file.
* gdb.threads/signal-delivered-right-thread.c: New file.
* gdb.threads/signal-delivered-right-thread.exp: New file.
This patch removes some GDBSERVER checks from nat/linux-ptrace.c.
Currently the code uses a compile-time check to decide whether some
flags should be used. This changes the code to instead let users of
the module specify an additional set of flags; and then changes gdb's
linux-nat.c to call this function. At some later date, when the back
ends are fully merged, we will be able to remove this function again.
gdb/
2014-07-24 Tom Tromey <tromey@redhat.com>
Gary Benson <gbenson@redhat.com>
* nat/linux-ptrace.c (additional_flags): New global.
(linux_test_for_tracesysgood, linux_test_for_tracefork): Use
additional_flags; don't check GDBSERVER.
(linux_ptrace_set_additional_flags): New function.
* nat/linux-ptrace.h (linux_ptrace_set_additional_flags):
Declare.
* linux-nat.c (_initialize_linux_nat): Call
linux_ptrace_set_additional_flags.
Since we use tkill everywhere, using kill to try to kill each lwp
individually looks suspiciously odd. We should really be using tgkill
everywhere, but at least while we don't get there this makes us
consistent.
gdb/gdbserver/
2014-07-16 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_kill_one_lwp): Use kill_lwp, not kill.
gdb/
2014-07-16 Pedro Alves <palves@redhat.com>
* linux-nat.c (kill_callback): Use kill_lwp, not kill.
Pedro Alves
Gary Benson
Antoine Tremblay
Sergio Durigan Junior
Joel Brobecker
Simon Marchi
Doug Evans
Don Breazeal
Andreas Arnez
Doug Evans
Tom Tromey