From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30871 invoked by alias); 26 Apr 2009 17:48:38 -0000 Received: (qmail 30857 invoked by uid 22791); 26 Apr 2009 17:48:37 -0000 X-SWARE-Spam-Status: No, hits=1.4 required=5.0 tests=AWL,BAYES_00,BOTNET,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout1.012.net.il (HELO mtaout1.012.net.il) (84.95.2.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 26 Apr 2009 17:48:31 +0000 Received: from conversion-daemon.i-mtaout1.012.net.il by i-mtaout1.012.net.il (HyperSendmail v2007.08) id <0KIP00L00YOQ1T00@i-mtaout1.012.net.il> for gdb-patches@sourceware.org; Sun, 26 Apr 2009 20:48:28 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.127.175.232]) by i-mtaout1.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KIP00J1PYSQI610@i-mtaout1.012.net.il>; Sun, 26 Apr 2009 20:48:27 +0300 (IDT) Date: Sun, 26 Apr 2009 17:48:00 -0000 From: Eli Zaretskii Subject: Re: [PATCH 3/3] catch syscall -- try 5 -- Build-system, testcase, documentation and extra command In-reply-to: <1240731135.13755.19.camel@miki> To: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= Cc: gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <8363grfgr5.fsf@gnu.org> References: <1240446783.2000.83.camel@miki> <83prf1f7hb.fsf@gnu.org> <1240731135.13755.19.camel@miki> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-04/txt/msg00717.txt.bz2 > From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= > 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 . > > > > @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.