Hi, all,
In order to implement fbt tracing, dtrace needs to modify the
instructions at the start of the function being traced. And as I am
interested in the internal of dtrace,
I wrote a dtrace script to verify:
#!/usr/sbin/dtrace -s
fbt::bge_send:entry
/1/
{
stack();
ustack();
}
Before running the script, I using mdb to check the assembly of
bge_send:> bge_send::dis -n 10
bge_send: pushl %ebp
bge_send+1: movl %esp,%ebp
bge_send+3: subl $0x30,%esp
bge_send+6: andl $0xfffffff0,%esp
bge_send+9: pushl %ebp
bge_send+0xa: pushl %ebx
bge_send+0xb: pushl %esi
bge_send+0xc: pushl %edi
bge_send+0xd: movl 0xc(%ebp),%ebx
bge_send+0x10: movl 0xc(%ebx),%esi
bge_send+0x13: pushl $0x8100
bge_send+0x18: movl (%esp),%eax
bge_send+0x1b: bswap %eax
bge_send+0x1d: shrl $0x10,%eax
bge_send+0x20: addl $0x4,%esp
bge_send+0x23: movzwl 0xc(%esi),%ecx
bge_send+0x27: cmpl %eax,%ecx
and when running the script, I check the assembly again and it
becomes:> bge_send::dis -n 10
bge_send: lock movl %esp,%ebp
bge_send+3: subl $0x30,%esp
bge_send+6: andl $0xfffffff0,%esp
bge_send+9: pushl %ebp
bge_send+0xa: pushl %ebx
bge_send+0xb: pushl %esi
bge_send+0xc: pushl %edi
bge_send+0xd: movl 0xc(%ebp),%ebx
bge_send+0x10: movl 0xc(%ebx),%esi
bge_send+0x13: pushl $0x8100
bge_send+0x18: movl (%esp),%eax
bge_send+0x1b: bswap %eax
bge_send+0x1d: shrl $0x10,%eax
bge_send+0x20: addl $0x4,%esp
bge_send+0x23: movzwl 0xc(%esi),%ecx
bge_send+0x27: cmpl %eax,%ecx
bge_send+0x29: jne +0xa4 <bge_send+0xd3>
Then I am puzzled, how can the instrumented code give control to dtrace
at the beginning of the function, from the assembly code above?
Thanks,
Zhijun
> and when running the script, I check the assembly again and it becomes: > > bge_send::dis -n 10 > bge_send: lock movl %esp,%ebp > bge_send+3: subl $0x30,%esp > bge_send+6: andl $0xfffffff0,%esp > bge_send+9: pushl %ebp > bge_send+0xa: pushl %ebx > bge_send+0xb: pushl %esi > bge_send+0xc: pushl %edi > bge_send+0xd: movl 0xc(%ebp),%ebx > bge_send+0x10: movl 0xc(%ebx),%esi > bge_send+0x13: pushl $0x8100 > bge_send+0x18: movl (%esp),%eax > bge_send+0x1b: bswap %eax > bge_send+0x1d: shrl $0x10,%eax > bge_send+0x20: addl $0x4,%esp > bge_send+0x23: movzwl 0xc(%esi),%ecx > bge_send+0x27: cmpl %eax,%ecx > bge_send+0x29: jne +0xa4 <bge_send+0xd3> > > Then I am puzzled, how can the instrumented code give control to dtrace > at the beginning of the function, from the assembly code above?#lock is illegal on a movl(*); the instruction induces an illegal opcode trap, which DTrace has hooked into. (We could have done it just as well with an INT 3; the #lock mechanism is used for historical reasons.) - Bryan -------------------------------------------------------------------------- Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc (*) Students of Famous Disasters in Microprocessor Implementation will recognize the illegality of the #lock prefix: it was the failure to implement this illegality correctly on a "cmpxchg8b %eax" instruction that became known as the "f00f" bug -- a bug for which Intel was damned lucky to discover a workaround...
Very helpful. Thanks. Regards, Zhijun Bryan Cantrill wrote:>> and when running the script, I check the assembly again and it becomes: >> >>> bge_send::dis -n 10 >>> >> bge_send: lock movl %esp,%ebp >> bge_send+3: subl $0x30,%esp >> bge_send+6: andl $0xfffffff0,%esp >> bge_send+9: pushl %ebp >> bge_send+0xa: pushl %ebx >> bge_send+0xb: pushl %esi >> bge_send+0xc: pushl %edi >> bge_send+0xd: movl 0xc(%ebp),%ebx >> bge_send+0x10: movl 0xc(%ebx),%esi >> bge_send+0x13: pushl $0x8100 >> bge_send+0x18: movl (%esp),%eax >> bge_send+0x1b: bswap %eax >> bge_send+0x1d: shrl $0x10,%eax >> bge_send+0x20: addl $0x4,%esp >> bge_send+0x23: movzwl 0xc(%esi),%ecx >> bge_send+0x27: cmpl %eax,%ecx >> bge_send+0x29: jne +0xa4 <bge_send+0xd3> >> >> Then I am puzzled, how can the instrumented code give control to dtrace >> at the beginning of the function, from the assembly code above? >> > > #lock is illegal on a movl(*); the instruction induces an illegal opcode trap, > which DTrace has hooked into. (We could have done it just as well with an > INT 3; the #lock mechanism is used for historical reasons.) > > - Bryan > > -------------------------------------------------------------------------- > Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc > > (*) Students of Famous Disasters in Microprocessor Implementation will > recognize the illegality of the #lock prefix: it was the failure to implement > this illegality correctly on a "cmpxchg8b %eax" instruction that became > known as the "f00f" bug -- a bug for which Intel was damned lucky to > discover a workaround... > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20060902/8ef6aa9c/attachment.html>