Re: [PATCH 1/4] catch syscall -- try 4 -- Architecture-independent part

["Sérgio Durigan Júnior" <sergiodj@linux.vnet.ibm.com>]

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