This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP
- From: Pedro Alves <palves at redhat dot com>
- To: Josh Stone <jistone at redhat dot com>, gdb-patches at sourceware dot org
- Cc: philippe dot waroquiers at skynet dot be, sergiodj at redhat dot com, eliz at gnu dot org, xdje42 at gmail dot com
- Date: Thu, 26 Nov 2015 10:34:18 +0000
- Subject: Re: [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP
- Authentication-results: sourceware.org; auth=none
- References: <1446169946-28117-1-git-send-email-jistone at redhat dot com> <1448506425-24691-1-git-send-email-jistone at redhat dot com>
On 11/26/2015 02:53 AM, Josh Stone wrote:
> The ptrace options should be set as soon as we know a thread is stopped,
> so no events can be missed. There's an arch-setup early return that was
> effectively delaying this update before, and I found for instance that
> the first syscall event wouldn't be properly reported with TRACESYSGOOD.
> It's now more similar to the way that gdb/linux-nat.c handles it.
Hmm, I'm confused on how this resulted in the first syscall being misssed.
That early return happens when we're not executing the real inferior
yet -- the process is still running the "gdbserver --wrapper WRAPPER"
It's pedantically good, though not crucial, to set PTRACE_O_TRACEEXEC early for
that scenario, to get a real PTRACE_EVENT_EXEC event instead of a bare SIGTRAP
when the exec wrapper (or in the future, the shell, when we start inferiors
with the shell, like gdb does, for arg expansion and globbing) actually execs.
If the shell/wrapper forks, enabling fork events while still executing the
wrapper/shell breaks startup -- server.c:start_inferior. The gdb
version (fork-child.c:startup_inferior) does handle TARGET_WAITKIND_FORKED,
but AFAICS forgets detaching/resuming the child...
We _must_ not catch syscall events while running the exec wrapper (or
the shell), otherwise server.c:start_inferior would get confused for seeing
unexpected syscall stops. If the backend treats syscall catchpoints, it's OK,
since gdb won't insert catchpoints in the process until after vRun returns,
indicating the process is stopped at the entry point. IIRC, gdb actually
does NOT handle catchpoint locations per-inferior today, but as long as
the backend side thinks of catchpoints per-inferior, we can fix the GDB side.
So all in all, I'm not sure this actually buys us anything other than need
to fix the wrapper/shell-forks case.
> 2015-11-25 Josh Stone <firstname.lastname@example.org>
> * linux-low.c (linux_low_filter_event): Set ptrace options as soon as
> each thread is stopped, even before arch-specific setup.