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

[Eli Zaretskii <eliz at gnu dot org>]

> From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= <sergiodj@linux.vnet.ibm.com>
> Cc: gdb-patches@sourceware.org
> Date: Sun, 26 Apr 2009 04:32:14 -0300
> 
> >   @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.

I'm open to other opinions, if there are any.  Anyone?

> > > +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.

That's fine with me.  Please don't regard my comments as rejection of
what you've done.

> > 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], ...)

Fine with me.

Thanks.