Ability to tell the difference between normal and syscall traps

Kostik Belousov kostikbel at gmail.com
Sun May 9 13:58:14 UTC 2010


On Sun, May 09, 2010 at 08:33:03AM +0300, Ali Polatel wrote:
> Kostik Belousov yazm??:
> > On Sat, May 08, 2010 at 02:15:09PM +0300, Ali Polatel wrote:
> > > Does FreeBSD's ptrace have a way to tell the difference between normal
> > > traps and those caused by a system call?
> > > 
> > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option to the
> > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 in the
> > > syscall number when delivering system call traps,
> > > (i.e., deliver (SIGTRAP | 0x80)).
> > > 
> > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request looks
> > > related but can't be sure.
> > > 
> > > ?: http://linux.die.net/man/2/ptrace
> > 
> > There is already procfs(5)-based interface to get a reason for stop.
> > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs.
> > 
> > The interface can be lifted to ptrace(2), but I think using the capacity
> > of procfs is not wrong there.
> 
> Hmm ok, I've been playing around with PIOCSTATUS but it doesn't seem to
> work, there's not much documentation about it either so I figured I'll
> just ask.
> 
> The code is here: http://alip.github.com/code/piocstatus.c
> 
> The traced child is stopped at the beginning of a system call. I await
> that the PIOCSTATUS request sets ps.why to S_SCE but it's always zero.
> Can you help me figure out what I'm doing wrong? :)

Apparently I missed the fact that S_PT_SCE and S_SCE are different
flags. It seems you have to use procfs stop events (PIOCBIS) and
procfs-based loop to get p_step set to 1.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20100509/19e7bb9a/attachment.pgp


More information about the freebsd-hackers mailing list