This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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.


>>> * 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:
>   <;h=458c8db89f7e9913da6fa67c3df73404375c436b>
>   (discussion: <>)
> meanwhile, which should help address this issue (though it doesn't fix
> the whole problem).  You might be interested in reading
> 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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]