Date: Mon, 10 May 2010 20:09:47 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Ali Polatel <alip@exherbo.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Ability to tell the difference between normal and syscall traps Message-ID: <20100510170947.GP83316@deviant.kiev.zoral.com.ua> In-Reply-To: <20100510164847.GF8186@harikalardiyari> 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> <20100510164847.GF8186@harikalardiyari>
next in thread | previous in thread | raw e-mail | index | archive | help
--r/w8vo2lxBmCPGjQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 10, 2010 at 07:48:47PM +0300, Ali Polatel wrote: > Kostik Belousov yazm??: > > 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 betwe= en normal > > > > > > > traps and those caused by a system call? > > > > > > >=20 > > > > > > > On Linux? this is possible by passing PTRACE_O_TRACESYSGOOD o= ption to the > > > > > > > ptrace request PTRACE_SETOPTIONS which makes the kernel set b= it 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 reque= st 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 = 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= capacity > > > > > > of procfs is not wrong there. > > > > >=20 > > > > > Hmm ok, I've been playing around with PIOCSTATUS but it doesn't s= eem 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. > > >=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 resum= e. > > > 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 writin= g a > > > library and for its unit tests I need to use the SIGSTOP method becau= se > > > 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> >=20 > 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. >=20 > 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. Is this needed ? The question is not rhetorical, I am trying to understand what prevents use of PT_TO_SCE and checking the syscall number ? You would screen for SYS_execve or SYS_fexecve and reset the debugger state on SIGTRAP that is supplied to the debugger before first instruction of new image is executed. Can you, please, extract and provide me with the code you used to test the PL_EVENT_SCE/SCX patch ? --r/w8vo2lxBmCPGjQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (FreeBSD) iEYEARECAAYFAkvoPdoACgkQC3+MBN1Mb4jitACgzfaQqgRwIkqxRKy8YVWQe1UF +q4AoLT1uZ9D2PWIBo8PAzw8Dac89t8c =lDGb -----END PGP SIGNATURE----- --r/w8vo2lxBmCPGjQ--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100510170947.GP83316>