Date: Mon, 10 May 2010 19:48:47 +0300 From: Ali Polatel <alip@exherbo.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps Message-ID: <20100510164847.GF8186@harikalardiyari> In-Reply-To: <20100509214359.GJ83316@deviant.kiev.zoral.com.ua> References: <20100508111509.GB8186@harikalardiyari> <20100508123626.GC83316@deviant.kiev.zoral.com.ua> <20100509053303.GD8186@harikalardiyari> <20100509135807.GH83316@deviant.kiev.zoral.com.ua> <20100509182851.GE8186@harikalardiyari> <20100509214359.GJ83316@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--wtjvnLv0o8UUzur2 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 09:28:51PM +0300, Ali Polatel wrote: > > Kostik Belousov yazm??: > > > 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? > > > > > >=20 > > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD opt= ion 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)). > > > > > >=20 > > > > > > I'm not sure if this is possible on FreeBSD. PT_LWPINFO request= looks > > > > > > 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 st= op. > > > > > 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 c= apacity > > > > > of procfs is not wrong there. > > > >=20 > > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't see= m 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 aw= ait > > > > that the PIOCSTATUS request sets ps.why to S_SCE but it's always ze= ro. > > > > 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. > >=20 > > So I can't use ptrace() together with ioctl() based tracing. > > Fair enough... > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > The code is here: http://alip.github.com/code/piocstatus-2.c > >=20 > > 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 > I see. You could try this patch. It requires HEAD or recent RELENG_8 > to be applicable. I added PL_EVENT_SCE/SCX to PT_LWPINFO for i386 and > amd64. Please note that I did not tested it, only booted the kernel to > make sure that it does not break too ugly. >=20 > diff --git a/sys/amd64/amd64/trap.c b/sys/amd64/amd64/trap.c > index f3dba94..f97f875 100644 <snip the nice patch> Looks great, I could only test it basically but it seems to work fine. If this is merged, truss can make use of this too. Another question is how hard is it to implement PL_EVENT_EXEC? This could be useful for truss as it updates the execution type of the process after successful execve() calls afaict. --=20 Regards, Ali Polatel --wtjvnLv0o8UUzur2 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEABECAAYFAkvoOO8ACgkQQU4yORhF8iCtqwCeK9cYJKBLwt6oK9RP+8wJBnpQ GR8AoKee33R8M0oLdf683WIkxKo0aBWR =GWan -----END PGP SIGNATURE----- --wtjvnLv0o8UUzur2--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100510164847.GF8186>