This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 1/4] catch syscall -- try 4 -- Architecture-independent part
- From: Sérgio Durigan Júnior <sergiodj at linux dot vnet dot ibm dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Pedro Alves <pedro at codesourcery dot com>, gdb-patches at sourceware dot org
- Date: Mon, 09 Mar 2009 12:09:24 -0300
- Subject: Re: [PATCH 1/4] catch syscall -- try 4 -- Architecture-independent part
- 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> <1236539758.28243.6.camel@miki> <20090309131856.GA16796@caradoc.them.org>
On Mon, 2009-03-09 at 09:18 -0400, Daniel Jacobowitz wrote:
> On Sun, Mar 08, 2009 at 04:15:58PM -0300, Sérgio Durigan Júnior wrote:
> > > > > > +# 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.
> >
> > So I won't modify anything, ok?
>
> Sorry, I was unclear - I still suggest that you drop the extra gdbarch
> methods and rearrange. There's nothing Linux-specific about what you
> have.
>
> > > Not sure that the flag exists any more, but you're trying to avoid it
> > > when called by startup_inferior. I suppose you could use the
> > > inferior_created observer (not new_inferior! The distinction is not
> > > too clear in the manual but that one is too early). The problem is,
> > > again, that this flag needs to be per-inferior.
> > >
> > > Pedro, any thoughts?
> >
> > What do you mean by "Not sure that the flag exists any more"? Also, I'm
> > waiting for Pedro's reply.
>
> There used to be a global variable for this, but I believe it was
> removed.
Hmm, right. I need to make a correction about an information I gave you.
I tried to remove the call to target_passed_by_entrypoint, i.e., leaving
the code like this:
if (catch_syscall_enabled () > 0) ...
What happens is that the code does not freeze. GDB still works with
this, and as far as I could investigate it shows everything fine.
Therefore, I think this function is not needed at all.
Regards,
--
Sérgio Durigan Júnior
Linux on Power Toolchain - Software Engineer
Linux Technology Center - LTC
IBM Brazil