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

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

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