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
[email protected]
