From owner-freebsd-hackers@FreeBSD.ORG Sun May 9 18:28:56 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A6DEE106566B for ; Sun, 9 May 2010 18:28:56 +0000 (UTC) (envelope-from alip@exherbo.org) Received: from bach.exherbo.org (bach.exherbo.org [78.47.197.147]) by mx1.freebsd.org (Postfix) with ESMTP id 3C09D8FC12 for ; Sun, 9 May 2010 18:28:56 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=harikalardiyari ident=alip) by bach.exherbo.org with esmtp (Exim 4.69) (envelope-from ) id 1OBBFG-0000St-MX; Sun, 09 May 2010 18:28:55 +0000 Date: Sun, 9 May 2010 21:28:51 +0300 From: Ali Polatel To: Kostik Belousov Message-ID: <20100509182851.GE8186@harikalardiyari> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tVmo9FyGdCe4F4YN" Content-Disposition: inline In-Reply-To: <20100509135807.GH83316@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 18:28:56 -0000 --tVmo9FyGdCe4F4YN Content-Type: text/plain; charset=iso-8859-9 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Kostik Belousov yazm=FD=FE: > 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 nor= mal > > > > traps and those caused by a system call? > > > >=20 > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD option = to the > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set bit 7 i= n the > > > > syscall number when delivering system call traps, > > > > (i.e., deliver (SIGTRAP | 0x80)). > > > >=20 > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request loo= ks > > > > related but can't be sure. > > > >=20 > > > > ?: http://linux.die.net/man/2/ptrace > > >=20 > > > There is already procfs(5)-based interface to get a reason for stop. > > > Look at the ioctl PIOCSTATUS. Yes, you have to mount procfs. > > >=20 > > > The interface can be lifted to ptrace(2), but I think using the capac= ity > > > of procfs is not wrong there. > >=20 > > 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. > >=20 > > The code is here: http://alip.github.com/code/piocstatus.c > >=20 > > 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? :) >=20 > 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. So I can't use ptrace() together with ioctl() based tracing. Fair enough... I'm trying to write the ioctl() based equivalent of what I've started but I can't figure out how to start tracing by forking a new child. Here's how I do it on Linux: fork() child: call kill(getpid(), SIGSTOP) and wait for the parent to resume. parent: wait for the child, set up tracing options and start tracing. I can directly use execve() so the child will stop too but I'm writing a library and for its unit tests I need to use the SIGSTOP method because I won't do any exec'ing. I tried to do the same with ioctl(), it works most of the time but it hangs every now and then at PIOCWAIT. I'm inclined to think there's a race condition but I couldn't figure out why. The code is here: http://alip.github.com/code/piocstatus-2.c Fwiw this is about a library called pinktrace(http://dev.exherbo.org/~alip/pinktrace) I'm trying to write. Its aim is to be a lightweight portable tracing library with multiple backends (like procfs and ptrace etc.) I think this could prove useful for many people who need to do tracing and doesn't want to bother with platform specific details. --=20 Regards, Ali Polatel --tVmo9FyGdCe4F4YN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvm/uMACgkQQU4yORhF8iCZPwCgsyZ6o3UPyF+WmX5swBo4sobJ IjUAn1aJlFiESjAsf+Xs4C9XWLU5xTmd =RXqQ -----END PGP SIGNATURE----- --tVmo9FyGdCe4F4YN--