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

[Daniel Jacobowitz <drow at false dot org>]

On Sun, Mar 29, 2009 at 03:50:26PM -0300, Sérgio Durigan Júnior wrote:
> ~"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"

> So, what do you think of it? Analyzing it, I think it's not so useful
> except for the (obvious) part ~"Catchpoint 1 ...".

Right.  There ought to be a new reason="..." entry; search for
EXEC_ASYNC_BREAKPOINT_HIT.  There should probably be some semantic
fields, too, like "old" for watchpoints.

> > > > > +# 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?

Yes, that's what I mean.

The way I think about this is that every gdbarch routine is a way for
some architecture to handle things differently.  If we can make every
architecture work the same way, we should do that instead.

-- 
Daniel Jacobowitz
CodeSourcery