This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/3] catch syscall -- try 5 -- Build-system, testcase, documentation and extra command
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Sun, 26 Apr 2009 20:48:30 +0300
- Subject: Re: [PATCH 3/3] catch syscall -- try 5 -- Build-system, testcase, documentation and extra command
- References: <1240446783.2000.83.camel@miki> <83prf1f7hb.fsf@gnu.org> <1240731135.13755.19.camel@miki>
- Reply-to: 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.