Re: [PATCH 3/3] catch syscall -- try 5 -- Build-system, testcase, documentation and extra command

[Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>]

Hi Eli,

Thanks for the review.  Comments below.

On Sat, 2009-04-25 at 11:44 +0300, Eli Zaretskii wrote:
> > From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= <sergiodj@linux.vnet.ibm.com>
> > Date: Wed, 22 Apr 2009 21:33:02 -0300
> > +@var{name} can be any valid system call name in the system.  You can
> > +use the @value{GDBN} command-line completion facilities to list the
> > +available choices.  @xref{Completion,, Command Completion}, for
> > +details on how to do this.
> > +
> > +You may also specify the system call numerically.  This may be useful
> > +if @value{GDBN} does not fully support your system's list of system
> > +calls.
> 
> This text is okay, but it could still leave the reader wondering about
> too many things.  How does GDB know which syscalls are available? what
> are the possible syscall numbers, and how do I know which ones are
> valid? what happens if I use a name or number that are invalid?
> 
> The examples you give below answer some of these questions, and hint
> to answers to others, but I think we still need some general text
> about these issues, and we need a text that is as system-independent
> as possible.  So I suggest this text instead:
> 
>   @var{name} can be any system call name that is valid for the
>   underlying OS.  Just what syscalls are valid depends on the OS.  On
>   GNU and Unix systems, you can find the full list of valid syscall
>   names on <PUT HERE THE NAME OF SYSTEM FILE WHERE TO FIND THE LIST>.
> 
>   @c For MS-Windows, the syscall names and the corresponding numbers
>   @c can be found, e.g., on this URL:
>   @c http://www.metasploit.com/users/opcode/syscalls.html
>   @c but we don't support Windows syscalls yet.
> 
>   Normally, @value{GDBN} knows in advance which syscalls are valid for
>   each OS, so you can use the @value{GDBN} command-line completion
>   facilities (@pxref{Completion,, command completion}) to list the
>   available choices.
> 
>   You may also specify the system call numerically.  A syscall's
>   number is the value passed to the OS's syscall dispatcher to
>   identify the requested service.  When you specify the syscall by its
>   name, @value{GDBN} uses its database of syscalls to convert the name
>   into the corresponding numeric code, but using the number directly
>   may be useful if @value{GDBN}'s database does not have the complete
>   list of syscalls on your system (e.g., because @value{GDBN} lags
>   behind the OS upgrades).
> 
> WDYT?

Well, it's fine by me.  If you think the user will feel more comfortable
by reading this, then I'll modify the text as suggested.

> > +@smallexample
> > +(@value{GDBP}) catch syscall chroot
> > +Catchpoint 1 (syscall(s) 'chroot')
> 
> Why do you have the "(s)" part in this message?  You are announcing a
> catchpoint for a single syscall, right?

Yeah.  I'll do a more selective filtering here, printing singular/plural
correctly.

> > +Catchpoint 1 (call to syscall 'close'), \
> > +	   0xffffe424 in __kernel_vsyscall ()
> 
> > +Catchpoint 1 (returned from syscall 'close'), \
> > +	0xffffe424 in __kernel_vsyscall ()
> 
> Is this all GDB displays when a syscall is caught?  I thought it also
> displayed the return code and the syscall parameters, like strace
> does.  If we don't do that, this facility looks much less useful than
> it sounds, doesn't it?  I realize that the user could glean all that
> information by using the normal GDB commands, but for that, she would
> need to know the some intimate details of the syscall dispatched
> (__kernel_vsyscall in this case), right?

I'm sorry, but this is how the "catch syscall" was implemented since the
beginning.  For the moment, GDB only prints the syscall name when the
catchpoint is triggered; it's obviously my intention to expand this in
the future (by making GDB print the syscall arguments, or its return
value for example), but I unfortunately don't have time to do it now.
However, IMHO I don't think it's a "much less useful" feature just
because of that.  As far as I know, everybody here knew that the catch
syscall was all about printing the syscall name (for now, at least), and
nonetheless I've seen people very enthusiastic about it.

If you think the feature should include more things than it actually
does, then I'd be very happy to accept some help from you in order to
make it more complete.

> Also, how about showing the syscall number together with its name?

This is a good idea.  Do you have any preference about the printing
style?  I was thinking in something like:

Catchpoint 1 (call to syscall 'xyz' [number], ...)

What do you think?

Regards,

-- 
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil