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 Friday, September 11 2015, Josh Stone wrote:

> Hi all,
> I've been using Philippe's QCatchSyscalls patch[1] for gdbserver, and
> I'd like to reopen the discussion about merging this patch.  Philippe
> told me would be fine with me taking this up, as he doesn't have time to
> work on it now.
> [1]
> I've rebased the patch onto current gdb.git master, attached.  Some
> things are simplified by various refactoring done in the last two years,
> but otherwise I didn't change any capability from what he had.
> I haven't included formalities like ChangeLogs here, because I would
> like to get basic consensus on the approach first.  I also don't know
> the right way to approach authorship here, between what Philippe
> originally wrote and my changes since, for what's ultimately committed.
> I tested catch-syscall.exp on Fedora 22 x86_64, for targets unix,
> native-gdbserver, and native-extended-gdbserver, and all passed.
> Philippe pointed me to his last summary of issues, which I'd like to
> start the discussion with:

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:


  (discussion: <>)

meanwhile, which should help address this issue (though it doesn't fix
the whole problem).  You might be interested in reading as well.

>> * ensure QCatchSyscall packet can (in the future) be extended with
>>   a COND_LIST (similar to the Z packets).
>>   To do that, I suggest to have the QCatchSyscalls separating syscall
>>   numbers with a , rather than a ;
>>   (so that a ; can be used later to separate the list of syscalls
>>    from the COND_LIST)
>>   Note: Luis suggested the alternative to have a packet
>>   QInsertCatchPoint:[fork|syscall|exec|...]
>>   Then gdbserver will tell in QSupported that it e.g. support
>>      QInsertCatchPoint=syscall,fork
>>   For what concerns the problem of identifying which catchpoint
>>   to remove in the QRemoveCatchPoint: not too sure we need
>>   an catch point id for that. We can assume that an QInsertCatchPoint
>>   of a certain kind fully replace the previously inserted catchpoint
>>   of the same kind. A QRemoveCatchpoint removes completely
>>   the catchpoint of the same kind.
>>   I can go the QInsertCatchPoint way if it is confirmed this is a better
>>   approach.
> I notice that fork and vfork events have since been implemented on their
> own as simple qSupported flags.  So I guess this idea of a generic
> QInsertCatchPoint idea was dropped?

That's my understanding as well.  I'd say go ahead with QCatchSyscalls.

>> * Need to investigate the bug in gdb 'catch syscall' flip/flop logic.
>>   If this logic can be fixed, then have gdbserver and gdb using
>>   the same logic.
> I guess this is referring gdb's simple toggling, vs gdbserver's ENOSYS
> method of detecting syscall entry vs return.  Can someone point to the
> bug in gdb's flip/flop?  (strace is also a toggler, btw)
> FWIW, I think it is possible for Linux to know this precisely.  AFAIK
> the only way to catch a syscall return is with PTRACE_SYSCALL from a
> syscall entry *or* from one of the mid-syscall events, like a
> PTRACE_EVENT_FORK.  Any other time, a syscall stop can only be entry.
> I can see how flip/flop might get confused if 'catch syscall' was only
> enabled when the target was already stopped on that fork, for instance.
>  But if you mark that fork like being in an entry, then it will toggle
> to return correctly afterward.  Enabling 'catch syscall' at any other
> time should start at IGNORE, so the next is then entry.
> But I expect I'm missing things.  I'd like to hear what other demons are
> lurking around this...
> (I also know Sergio was tinkering with a ptrace patch to distinguish
> entry/return precisely in the kernel, which would be nice for all.)

I'll see if I can have some time this weekend to resume my work on this.


GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible

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