Re: [PATCH v2 1/2] gdbserver: Set Linux ptrace options ASAP

[Josh Stone <jistone@redhat.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"
> binary.

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.
> 
>>
>> gdb/gdbserver/ChangeLog:
>>
>> 2015-11-25  Josh Stone  <jistone@redhat.com>
>>
>> 	* linux-low.c (linux_low_filter_event): Set ptrace options as soon as
>> 	each thread is stopped, even before arch-specific setup.
> 
> Thanks,
> Pedro Alves
>