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: Josh Stone <jistone at redhat dot com>
- To: Pedro Alves <palves 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: Mon, 30 Nov 2015 10:50:27 -0800
- 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> <5656E02A dot 3090207 at redhat dot com>
On 11/26/2015 02:34 AM, Pedro Alves wrote:
> 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"
My memory of this is admittedly hazy by now. IIRC the first syscall
wasn't *completely* missed, just reported without TRACESYSGOOD in
effect, so it looked like a plain SIGTRAP.
I will try to dig in and characterize the problem I had better,
especially with your explanation of exec startup at hand. Thanks!
> 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 <email@example.com>
>> * linux-low.c (linux_low_filter_event): Set ptrace options as soon as
>> each thread is stopped, even before arch-specific setup.
> Pedro Alves