[RFC] reviving 'catch syscall' for gdbserver
Josh Stone
jistone@redhat.com
Sat Sep 19 00:28:00 GMT 2015
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?
More information about the Gdb-patches
mailing list