Re: Break on syscall?

[PAUL GILLIAM <pgilliam@us.ibm.com>]

On Fri, 2006-05-19 at 18:05 -0400, Daniel Jacobowitz wrote:
> On Fri, May 19, 2006 at 11:16:15PM +0200, Mark Kettenis wrote:
> > > Date: Fri, 19 May 2006 08:48:35 -0400
> > > From: Daniel Jacobowitz <drow@false.org>
> > > 
> > > On Fri, May 19, 2006 at 11:15:30AM +0100, Alex Bennee wrote:
> > > > Is it possible to get gdb to break on entering/exiting a syscall (rather
> > > > than breaking on entering libc or some such)?
> > > 
> > > This is not supported.
> > 
> > But I think it would be nice if we would support something like "catch
> > syscall", just like we support "catch fork".
> 
> Yes, probably.  I think I even started work on this once.  It's just a
> bit trickier.  Not only do you want to be able to decode arguments, but
> there are other problems... for example, I think procfs allows it, but
> traditionally ptrace has no way to request a single step and stop if
> entering a syscall, so you'd need an arch hook to detect it to handle
> that case.
> 
> A nice project for some rainy month :-)
> 
From the ptrace(2) man page on Linux:

PTRACE_SYSCALL, PTRACE_SINGLESTEP
       Restarts the stopped child as for PTRACE_CONT, but arranges  for
       the child to be stopped at the next entry to or exit from a sys-
       tem call, or after execution of a  single  instruction,  respec-
       tively.  (The child will also, as usual, be stopped upon receipt
       of a signal.)  From the parent’s  perspective,  the  child  will
       appear  to  have  been stopped by receipt of a SIGTRAP.  So, for
       PTRACE_SYSCALL, for example, the idea is to  inspect  the  argu-
       ments  to  the  system  call  at the first stop, then do another
       PTRACE_SYSCALL and inspect the return value of the  system  call
       at the second stop.  (addr is ignored.)

The 'ltrace' utility uses this to trace system calls.  It uses a sleazy
table (/etc/ltrace.cfg) to find out about their arguments...  GDB should
be able to do a much better job, although matching syscall numbers to
their associated library routines would be a challenge (at least for me
8-)

-=# Paul #=-

PS:  Here in Oregon, rainy months are the norm 8-)