Hi, thanks to a very helpful compiler geek at Sun, I made some progress :-) .
The dtrace error message ("assuming jump table") is misleading and the issue has actually nothing to do with jump tables. When instrumenting user functions, dtrace steps through all instructions of that very function in order to verify that there are no jump tables. Doing so, it uses dt_instr_size to check each instruction's size. In case dt_instr_size returns -1, dtrace refuses to instrument the function (issueing the error message "assuming jump table"). The two reasons triggering a return value of -1 are: 1) the instruction is not in the instruction set (checked via dtrace_disx86) or, 2) the instruction is a FASTTRAP_INSTR (meaning that another debugger has already instrumented the function). If there is no other debugger active, the error therefore really means "encountered illegal instruction in function". Digging deeper, I checked the reported code location with mdb: >> dcntrl_+857::dis > dcntrl_+0x85d: addl $-0x7,%eax > dcntrl_+0x860: ***ERROR--unknown op code*** > dcntrl_+0x862: movw (%rax),%es > dcntrl_+0x864: addl %eax,(%rax) > dcntrl_+0x866: addb %ah,0xf(%rsi) > dcntrl_+0x869: pushq %rdi > dcntrl_+0x86a: shlb $0x13,0xf(%rsi) > dcntrl_+0x86e: ***ERROR--unknown op code*** > dcntrl_+0x86f: movlpd %xmm0,0x8(%rsi) > dcntrl_+0x874: movlpd %xmm0,0x10(%rsi) There are unknown op-codes reported at exactly the locations dtrace complains about. Discussing this, it became clear that the probability of illegal op-codes is really very low. So I cross checked with dbx, which surprisingly showed the following: > (dbx) dis dcntrl+0x85d > 0x0000000000447bb5: dcntrl+0x085d: addl $0xfffffffffffffff9,%eax > 0x0000000000447bb8: dcntrl+0x0860: prefetchw 0x0000000000000100(%rsi) > 0x0000000000447bbf: dcntrl+0x0867: xorpd %xmm0,%xmm0 > 0x0000000000447bc3: dcntrl+0x086b: movlpd %xmm0,(%rsi) > 0x0000000000447bc7: dcntrl+0x086f: movlpd %xmm0,0x0000000000000008(%rsi) > 0x0000000000447bcc: dcntrl+0x0874: movlpd %xmm0,0x0000000000000010(%rsi) Observe that at the location where mdb reported an illegal opcode, dbx shows a prefetchw opcode. Obviously mdb is not aware of this operation. I believe the fact that two debuggers, using different disassembly functionality on the very same system is an interesting discussion in itself. I deduce from the above observation that dtrace somehow follows the same wisdom as mdb (instead of dbx) in disassembling user functions. There is a possible workaround (which is however not satisfying in the long run: If we instruct the compiler to generate less architecture-specific code (-xtarget=generic) chances increase that the binary contains no instructions offensive to dtrace. So I recompiled my application with f95 -xtarget=generic -m64 and veryfied that mdb does not report any illegal opcode in the function of interest. Indeed, the illegal op-codes disappeared. However, instrumenting the application with dtrace still does not yield the desired result. Checking with DTRACE_DEBUG: libdtrace DEBUG: creating probe pid10266:charmm:dcntrl_:return libdtrace DEBUG: error at 0 (assuming jump table) While the error location has changed, the error itself remains. Even more, checking the location with mdb does not reveal an illegal opcode: > dcntrl_::dis dcntrl_: pushq %rbp dcntrl_+1: movq %rsp,%rbp dcntrl_+4: pushq %rbx dcntrl_+5: pushq %r12 Summary: some mystery resolved, but instrumentation still defunct. Any help is appreciated! Thanks, Manfred PS: In case someone wants to know SunOS 5.10 Generic_141445-09 i86pc i386 i86pc version of "/opt/sunstudio12.1/bin/cc": Sun C 5.10 SunOS_i386 Patch 142363-02 2009/09/21 version of "/opt/sunstudio12.1/bin/f90": Sun Fortran 95 8.4 SunOS_i386 Patch 141852-01 2009/07/24 version of "/opt/sunstudio12.1/bin/dbx": Sun DBX Debugger 7.7 SunOS_i386 2009/06/03 -- This message posted from opensolaris.org _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org