Date: Tue, 13 Jul 2004 12:28:11 +0300 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: Steven Smith <sos22@cantab.net> Cc: sos22@srcf.ucam.org Subject: Re: Article on Sun's DTrace Message-ID: <20040713092811.GA288@pm514-9.comsys.ntu-kpi.kiev.ua> In-Reply-To: <20040712180933.GA1093@archibold.chu.cam.ac.uk> References: <1089501790.00086820.1089489001@10.7.7.3> <20040712115134.D6C3F14F@pm514-9.comsys.ntu-kpi.kiev.ua> <20040712180933.GA1093@archibold.chu.cam.ac.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040713092811.GA288>