From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 13 09:30:59 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 4FE7616A4CE for ; Tue, 13 Jul 2004 09:30:59 +0000 (GMT) Received: from comsys.ntu-kpi.kiev.ua (comsys.ntu-kpi.kiev.ua [194.125.244.127]) by mx1.FreeBSD.org (Postfix) with ESMTP id 238C743D49 for ; Tue, 13 Jul 2004 09:30:33 +0000 (GMT) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from pm514-9.comsys.ntu-kpi.kiev.ua (pm514-9.comsys.ntu-kpi.kiev.ua [10.18.54.109]) (authenticated bits=0)i6DCXinF039106 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2004 12:33:44 GMT Received: by pm514-9.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1000) id 5DF6114F; Tue, 13 Jul 2004 12:28:11 +0300 (EEST) Date: Tue, 13 Jul 2004 12:28:11 +0300 From: Andrey Simonenko To: Steven Smith Message-ID: <20040713092811.GA288@pm514-9.comsys.ntu-kpi.kiev.ua> References: <1089501790.00086820.1089489001@10.7.7.3> <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> <20040712180933.GA1093@archibold.chu.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040712180933.GA1093@archibold.chu.cam.ac.uk> User-Agent: Mutt/1.4.2.1i cc: freebsd-hackers@freebsd.org 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: Tue, 13 Jul 2004 09:30:59 -0000 On Mon, Jul 12, 2004 at 07:09:33PM +0100, Steven Smith wrote: > > 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. http://forum.sun.com/thread.jsp?forum=211&thread=19877 > > 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. Having read that bug report I began to think that they change several continues bytes in a function, probably they just search for well known commands sequence and atomically change one of them. I think it is possible to change almost any instruction on x86, just because changed instruction should be emulated after return from DTrace probe (this very actual for probes in userspace). Yes, you are right, using classic debugging technique for activating DTrace trampoline should work. One can find description of probe's activating for x86 in the 4.1 paragraph of the DTrace Usenix report. They talked about IDT and interrupt handler. I know that you know this, but... If an interrupt call for activating probe is used on x86, then this explains how it is possible to get offset of "ret" command (cs:eip from trap frame) and how probes work in the userspace (control goes to kernel, where it works with script's variables). Again, if every "ret" instructions or instructions before "ret" instructions are changed in a function (because an offset of "ret" instruction is available in :return probe), then to speed up instruction changing, it is possible to save offsets of probes entries in some well known sections of object files (during compilation phase for example) and if there isn't such section, then try to find probes entries on-the-fly by disassembling binary code. Wildcard probes can require changing at least two instructions in every of tens of thousands functions.