Re: [PATCH] Implement 'catch syscall' for gdbserver

[Josh Stone <jistone at redhat dot com>]

On 10/30/2015 01:12 AM, Eli Zaretskii wrote:
> The documentation parts are OK, with this minor comment and one
> question.  Here's the comment:
> 
>> +Note that if a syscall not member of the list is reported, @value{GDBN}
>                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> "a syscall not in the list" sounds simpler and more clear, and doesn't
> change the meaning.
> 
>> +will filter it if this syscall is not caught.  It is however more efficient
>> +to only report the needed syscalls.
> 
> The question is about the same sentence: maybe because I don't really
> use this stuff, I'm not sure I understand the distinction between
> "reported" and "caught" here: what does it mean for a syscall to be
> reported, but not caught?  Perhaps this text should be clarified to
> not cause such confusion.

"Reported" refers to syscall stop packets sent over the wire, whereas
"caught" refers to whether the GDB user had `catch syscall N` matching
that particular syscall.

I suppose a lazy stub could just report every syscall it finds, ignoring
the filter list, and let GDB filter what should actually be caught on
its side.  The new gdbserver is properly filtering though.

Actually, if that syscall list grows too big for a single packet
request, GDB will just send an unfiltered "QCatchSyscalls:1" and do the
filtering on its own anyway.  But maybe that's orthogonal to the
documentation of the packet protocol.

Should I reword it from the perspective that a stub implementation might
not respect the filter list?  Or should we disallow that possibility
altogether?