Re: [RFC] reviving 'catch syscall' for gdbserver

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