This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH v3 2/2] Implement 'catch syscall' for gdbserver
- 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: Fri, 11 Dec 2015 13:19:20 -0800
- Subject: Re: [PATCH v3 2/2] Implement 'catch syscall' for gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <1448506425-24691-1-git-send-email-jistone at redhat dot com> <1449196006-13759-1-git-send-email-jistone at redhat dot com> <1449196006-13759-2-git-send-email-jistone at redhat dot com> <5661929E dot 7020406 at redhat dot com> <566248F2 dot 5020908 at redhat dot com>
On 12/04/2015 06:16 PM, Josh Stone wrote:
> On 12/04/2015 05:18 AM, Pedro Alves wrote:
>> Quick question: What is supposed to happen to the QCatchSyscalls
>> when the process execs? I'm thinking of 64-bit inferior execing
>> 32-bit inferior, etc. The syscall numbers aren't necessarily shared
>> between the different architectures. This implementation deletes discards
>> the previous QCatchSyscalls on exec, and I think that's what makes sense,
>> but, I think that this should be explicit in the packet's description.
>
> Yes, I think it should be cleared to avoid any assumption about the
> architecture. I'll add a note in the description codifying this.
After exploration, I'm having second thoughts about this point. Yes,
the current implementation clears it, but only when PTRACE_O_TRACEEXEC
is enabled to actually get that event. That's only if the client sent
"qSupports:exec-events+". Otherwise, the server doesn't even know an
exec happened, so it can't really promise to reset the syscall table.
Since the server doesn't promise to always catch execs, I think we
should actually go the other way to stay consistent. Let the syscall
list be carried over, and document that clients should probably send a
new list after execs in case the architecture changed. Some clients may
just choose to live with the assumption that the arch is consistent in
their environment.
Thoughts?
>> I'm not sure gdb clears the inferior's "syscalls to the caught" VEC
>> on exec events, but it probably does (if it doesn't, I think it should.)
>
> I'll see if I can find out.
AFAICT the only time anything is removed from syscall_catchpoint's VEC
syscalls_to_be_caught is in breakpoint_ops->remove_location and ->dtor,
respectively remove_catch_syscall and dtor_catch_syscall. And since
this list isn't stored in the lwp structure itself, the exec doesn't
really affect anything. Right?