This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.

-- 
Daniel Jacobowitz
CodeSourcery


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]