From owner-freebsd-hackers@FreeBSD.ORG Mon Jul 12 18:08:20 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05E8516A4CE for ; Mon, 12 Jul 2004 18:08:20 +0000 (GMT) Received: from ppsw-8.csi.cam.ac.uk (ppsw-8.csi.cam.ac.uk [131.111.8.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AC5943D2D for ; Mon, 12 Jul 2004 18:08:19 +0000 (GMT) (envelope-from sos22@cantab.net) Received: from archibold.chu.cam.ac.uk ([131.111.131.102]:60490) by ppsw-8.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with smtp (Exim 4.34) id 1Bk5Dt-0005Gy-3h; Mon, 12 Jul 2004 19:08:17 +0100 Received: by archibold.chu.cam.ac.uk (sSMTP sendmail emulation); Mon, _d Jul 2004 19:09:33 +0100 Date: Mon, 12 Jul 2004 19:09:33 +0100 From: Steven Smith To: freebsd-hackers@freebsd.org Message-ID: <20040712180933.GA1093@archibold.chu.cam.ac.uk> References: <1089501790.00086820.1089489001@10.7.7.3> <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ X-Cam-AntiVirus: No virus found X-Cam-SpamDetails: Not scanned cc: sos22@srcf.ucam.org Subject: Re: Article on Sun's DTrace X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jul 2004 18:08:20 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > >> > It's also possible to put probes on the return instruction of the > >> > function. I'm not sure how they're actually finding that, though. > >> I think the return probe is done by adding a call probe that changes t= he=20 > >> return address. > > Yeah, I thought that when I first saw it, but the probe is passed the > > address of the return instruction when it fires, and I can't see how > > you could get that if it was just invoked by modifying the return > > address on the call stack. > Don't you think that they disassemble functions on-the-fly to find > out prolog and return sequence of a function? That is entirely plausible. > On their DTrace support forum there is the article about the problem > with different byte patterns of "movl %esp, %ebp" produced by > different assemblers. Do you have an URL for that? I can't seem to find it. > Also modifying functions on-the-fly require some sort of > synchronization: noone should run function which currently is being > modified (fbt provider). I suspect that the actual probe trigger is an int3 instruction, rather than a call, since that's a single byte and can therefore be atomically copied in over the start of any instruction. Any other processor either sees the value before the probe was activated (which is fine; it's just equivalent to the probe activating a split second later) ot afterwards (which is also fine). The x86 memory model is (I think; someone with more knowledge may want to correct me) strong enough to make that perfectly safe. (So the push %ebp part of the prolog becomes an int3 instruction in a single atomic operation, rather than just the first byte of a call instruction). I don't know enough about Sparcs to even speculate how it's done there. Steven. --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFA8tPdO4S8/gLNrjcRAsthAJ9zYS5sWzeC6ojvaB7JHICKop0rMQCeKlvj hwBEfShdlCHmosqRIw3meHI= =bVeR -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF--