From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27061 invoked by alias); 29 Mar 2009 18:56:53 -0000 Received: (qmail 27052 invoked by uid 22791); 29 Mar 2009 18:56:52 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_32 X-Spam-Check-By: sourceware.org Received: from e24smtp04.br.ibm.com (HELO e24smtp04.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 29 Mar 2009 18:56:44 +0000 Received: from d24relay01.br.ibm.com (d24relay01.br.ibm.com [9.8.31.16]) by e24smtp04.br.ibm.com (8.13.1/8.13.1) with ESMTP id n2TIrAHu020583 for ; Sun, 29 Mar 2009 15:53:10 -0300 Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by d24relay01.br.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n2TJu1U12895944 for ; Sun, 29 Mar 2009 16:56:01 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n2TIueBI003099 for ; Sun, 29 Mar 2009 15:56:41 -0300 Received: from [9.8.0.175] ([9.8.0.175]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n2TIueRn002616; Sun, 29 Mar 2009 15:56:40 -0300 Subject: Re: [PATCH 1/4] catch syscall -- try 4 -- Architecture-independent part From: =?ISO-8859-1?Q?S=E9rgio?= Durigan =?ISO-8859-1?Q?J=FAnior?= To: Daniel Jacobowitz Cc: Pedro Alves , gdb-patches@sourceware.org, teawater In-Reply-To: <20090227221133.GA12904@caradoc.them.org> References: <1232929831.26873.22.camel@miki> <200901260053.06295.pedro@codesourcery.com> <1232945747.26873.27.camel@miki> <1232989355.26873.39.camel@miki> <20090201193306.GJ4597@caradoc.them.org> <1235561189.14363.20.camel@miki> <20090227221133.GA12904@caradoc.them.org> Content-Type: text/plain; charset=iso-8859-1 Date: Sun, 29 Mar 2009 21:16:00 -0000 Message-Id: <1238352626.23609.14.camel@miki> Mime-Version: 1.0 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: 2009-03/txt/msg00661.txt.bz2 Hi Daniel, On Fri, 2009-02-27 at 17:11 -0500, Daniel Jacobowitz wrote: > > > > +/* Implement the "print_one" breakpoint_ops method for syscall > > > > + catchpoints. */ > > > > + > > > > +static void > > > > +print_one_catch_syscall (struct breakpoint *b, CORE_ADDR *last_addr) > > > > +{ > > > > > > Have you tried hitting a syscall catchpoint in MI mode, and is the > > > output anything useful? > > > > No, unfortunately I haven't. Actually, I must first learn how to use the > > MI interface, but that should not be hard :-). > > I'd suggest doing that as part of this submission so that we know > you're on the right track. It isn't too hard; you can start by > looking at the test logs from gdb.mi tests, if that helps. I finally had time to test this. In the example below, I tried to catch the syscall "chroot" using the same testcase used in the catch-syscall.exp test, and the output is: (gdb) maint set data-directory ./gdb &"maint set data-directory ./gdb\n" ^done (gdb) catch syscall chroot &"catch syscall chroot\n" ~"Catchpoint 1 (syscall(s) 'chroot')\n" ^done (gdb) run &"run\n" ~"Starting program: /tmp/test-syscall/gdb/testsuite/gdb.base/catch-syscall \n" =thread-group-created,id="1392" =thread-created,id="1",group-id="1392" ^running *running,thread-id="all" (gdb) =library-loaded,id="/lib/ld-linux.so.2",target-name="/lib/ld-linux.so.2",host-name="/lib/ld-linux.so.2",symbols-loaded="0" =library-loaded,id="/lib/libm.so.6",target-name="/lib/libm.so.6",host-name="/lib/libm.so.6",symbols-loaded="0" =library-loaded,id="/lib/libc.so.6",target-name="/lib/libc.so.6",host-name="/lib/libc.so.6",symbols-loaded="0" ~"\n" ~"Catchpoint 1 (call to syscall 'chroot'), 0xffffe424 in __kernel_vsyscall ()\n" ~"0xffffe424 <__kernel_vsyscall+16>:\tpop %ebp\n" *stopped,frame={addr="0xffffe424",func="__kernel_vsyscall",args=[]},thread-id="1",stopped-threads="all" (gdb) continue &"continue\n" ~"Continuing.\n" ^running *running,thread-id="all" (gdb) ~"\n" ~"Catchpoint 1 (returned from syscall 'chroot'), 0xffffe424 in __kernel_vsyscall ()\n" ~"0xffffe424 <__kernel_vsyscall+16>:\tpop %ebp\n" *stopped,frame={addr="0xffffe424",func="__kernel_vsyscall",args=[]},thread-id="1",stopped-threads="all" So, what do you think of it? Analyzing it, I think it's not so useful except for the (obvious) part ~"Catchpoint 1 ...". > > > > +# Fills the struct syscall (passed as argument) with the corresponding > > > > +# system call represented by syscall_number. > > > > +M:void:get_syscall_by_number:int syscall_number, struct syscall *s:syscall_number, s > > > > + > > > > +# Fills the struct syscall (passed as argument) with the corresponding > > > > +# system call represented by syscall_name. > > > > +M:void:get_syscall_by_name:const char *syscall_name, struct syscall *s:syscall_name, s > > > > + > > > > +# Returns the array containing the syscall names for the architecture. > > > > +M:const char **:get_syscall_names:void: > > > > > > If every target is going to use XML for this, these three do not need > > > to be gdbarch methods and the support code can move from linux-tdep.c > > > to xml-syscall.c. > > > > As far as I understood (from our discussion a few months ago), not every > > target is supposed to use the XML for syscalls. That's specially true > > for embedded systems and/or architectures for which the XML file is > > missing (for some obscure reason, don't know). That's why I thought it > > would be better not to generalize. > > I don't think this is a big deal. If it is, we can handle it the same > way as for target-descriptions: pre-compile them into GDB. With this you mean that I should remove the methods from gdbarch? Regards, -- Sérgio Durigan Júnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil