This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] reviving 'catch syscall' for gdbserver
- From: Josh Stone <jistone at redhat dot com>
- To: Sergio Durigan Junior <sergiodj at redhat dot com>
- Cc: gdb-patches at sourceware dot org, philippe dot waroquiers at skynet dot be, palves at redhat dot com
- Date: Fri, 18 Sep 2015 17:28:29 -0700
- Subject: Re: [RFC] reviving 'catch syscall' for gdbserver
- Authentication-results: sourceware.org; auth=none
- References: <55F3838A dot 4010005 at redhat dot com> <87vbbgpe1u dot fsf at redhat dot com>
On 09/11/2015 07:27 PM, Sergio Durigan Junior wrote:
> Hi Josh,
>
> First of all, thanks for the patch and for reviving. This e-mail is not
> really an in-depth reply; just a few things I would like to mention from
> the top of my head.
Thanks!
>>> * QCatchSyscalls contains target specific numbers (this is the
>>> above comment)
>>> => have gdbserver handling QCatchSyscalls packet per inferior
>>
>> Does this still need to be per-inferior? I do understand that syscall
>> numbers may differ, e.g. from i686 to x86_64 on the same target. Are
>> there any other examples of such things that are dealt with separately?
>
> I pushed:
>
> <https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=458c8db89f7e9913da6fa67c3df73404375c436b>
>
> (discussion: <https://sourceware.org/ml/gdb-patches/2014-11/msg00227.html>)
>
> meanwhile, which should help address this issue (though it doesn't fix
> the whole problem). You might be interested in reading
> https://sourceware.org/bugzilla/show_bug.cgi?id=10737 as well.
AIUI, you made the syscall tables per-arch, which is certainly good.
But what happens when there are multiple inferiors of different archs?
Are the syscall catchpoints per-inferior?
It occurred to me that exec switching archs would be a problem, which
Pedro also mentioned in PR10737#c5. So either gdbserver needs to be
told syscalls by name, and remap them on exec, or the client needs an
exec event so it can update a new QCatchSyscalls set itself.
I suppose the client could catch the exec syscall directly, but surely
it would be better to have a event based on PTRACE_EVENT_EXEC.
Something to add in the style of fork-event?