and when running the script, I check the assembly again and it becomes:
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
(*) 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...
3 messages in org.opensolaris.dtrace-discuss[dtrace-discuss] How does dtrace inst...
