From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23344 invoked by alias); 7 Nov 2008 04:03:10 -0000 Received: (qmail 23240 invoked by uid 22791); 7 Nov 2008 04:03:06 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 07 Nov 2008 04:02:20 +0000 Received: from d24relay01.br.ibm.com (unknown [9.8.31.16]) by igw1.br.ibm.com (Postfix) with ESMTP id D1E1432C239 for ; Fri, 7 Nov 2008 02:00:05 -0200 (BRDT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mA741tT64292688 for ; Fri, 7 Nov 2008 01:01:55 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id mA742GW8027470 for ; Fri, 7 Nov 2008 02:02:16 -0200 Received: from [9.8.9.146] ([9.8.9.146]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id mA742GY2027467; Fri, 7 Nov 2008 02:02:16 -0200 Subject: Re: [PATCH 4/4] 'catch syscall' feature -- Build system, documentation and testcase From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= To: tromey@redhat.com Cc: gdb-patches@sourceware.org In-Reply-To: References: <1225773088.24532.56.camel@miki> Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 07 Nov 2008 04:03:00 -0000 Message-Id: <1226030524.32321.112.camel@miki> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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: 2008-11/txt/msg00119.txt.bz2 Hi Tom, On Tue, 2008-11-04 at 09:32 -0700, Tom Tromey wrote: > >>>>> "Sérgio" == Sérgio Durigan Júnior writes: > > Sérgio> This last part modifies the build system (in order to > Sérgio> implement the GDB's datadir), adds the documentation and the > Sérgio> testcase for the new feature. > > Nice. > > Sérgio> +xml-syscall-copy: > Sérgio> + list='$(XML_SYSCALLS_FILES)' ; \ > Sérgio> + for file in $$list ; do \ > > Two nits here. > > First, if you build with builddir!=srcdir, you need to mkdir > XML_SYSCALLS_DIR here. > > Second, I think it would be nice to detect the case where > builddir==srcdir and not copy in that case. You're right. Thanks, I'll fix it. > Sérgio> +xml-syscall-install: > Sérgio> + $(SHELL) $(srcdir)/../mkinstalldirs \ > Sérgio> + $(DESTDIR)$(GDB_DATADIR_PATH)/$(XML_SYSCALLS_DIR) ; \ > > Using DESTDIR is nice attention to detail :-) Haha, I'm learning :-) > Sérgio> +# Also, the "install" target installs the syscalls' XML files in the system. > Sérgio> +install: all install-only xml-syscall-install > > I think install-only should depend on xml-syscall-install. > I believe the intent here is that "make install-only" will install > everything without rebuilding. Ok, consider it done. > Sérgio> +AC_ARG_WITH(gdb-datadir, > Sérgio> +[ --with-gdb-datadir=path Look for global separate data files in this path [DATADIR/gdb]], > > It is preferable, IMO, to use AS_HELP_STRING here. > There are some examples of this in gdb's configure.ac. OK, no problem by me. But I did a cut & paste from the other parts (specifically the DEBUGDIR part), which does exactly this :-). Just to let you know. > Sérgio> +AC_CONFIG_SUBDIRS(doc testsuite syscalls) > > You don't want this. There is no syscalls directory, and even if > there was, I would argue that it should not have its own configure > script. Sure, this was totally my fault. I'm sorry. > Sérgio> +@item syscall > Sérgio> +@itemx syscall @var{syscall name} > Sérgio> +@cindex break on call to/return from a system call > Sérgio> +A call to/return from a @code{syscall} -- similar to the @code{strace} > Sérgio> +utility. > > This needs a minor update now that "catch syscall" can take multiple > arguments. > > I didn't read the implementation patch in detail... if it parses > numeric syscalls, then that should be mentioned here. Yeah, thanks. Eli already pointed this error too. Thanks. > > Finally, instead of "call to/return from", how about "call to or > return from"? This is more grammatical and not much longer :-) > > Tom -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil