Hi,

finally I found the time to look again at the issue described above.

I was told (thanks Diane) that f95 generates jump tables when hitting SELECT 
CASE statements. Checking my code shows that there is no SELECT CASE statement 
anywhere near the function in question. Ruling out SELECT CASE statements 
leaves to possibilities: either there is some other Fortran construct resulting 
in jump tables, or the issue we face is not really about jump tables.

Checking 
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libdtrace/i386/dt_isadep.c
 it becomes clear, that the message "assuming jump table" is potentially 
misleading. It really covers everything resulting in an illegal opcode:

     93                 /*
     94                  * Assume the worst if we hit an illegal instruction.
     95                  */
     96                 if (size <= 0) {
     97                         dt_dprintf("error at %#lx (assuming jump 
table)\n", i);
     98                         return (1);
     99                 }

dt_instr_size returns -1 in case the instruction can not be disassembled or if 
a FASTTRAP is found.

    476         if (dtrace_disx86(&x86dis, cpu_mode) != 0)
    477                 return (-1);
    478 
    479         /*
    480          * If the instruction was a single-byte breakpoint, there may be
    481          * another debugger attached to this process. The original 
instruction
    482          * can't be recovered so this must fail.
    483          */
    484         if (x86dis.d86_len == 1 && instr[0] == FASTTRAP_INSTR)
    485                 return (-1);

Disassembling the binary using mdb reveals that indeed an illegal instruction 
is the source of the problem:

> dcntrl_+875::dis 
 dcntrl_+0x85b:                  movl   %edx,%eax
 dcntrl_+0x85d:                  subl   %ecx,%eax
 dcntrl_+0x85f:                  incl   %eax
 dcntrl_+0x861:                  cmpl   %edx,%ecx
 dcntrl_+0x863:                  jle    +0x4     <dcntrl_+0x867>
 dcntrl_+0x865:                  xorl   %eax,%eax
 dcntrl_+0x867:                  cmpl   $0x8,%eax
 dcntrl_+0x86a:                  jl     +0x50    <dcntrl_+0x8ba>
 dcntrl_+0x86c:                  movl   -0x9b8(%rbp),%eax
 dcntrl_+0x872:                  addl   $-0x7,%eax
 dcntrl_+0x875:                  ***ERROR--unknown op code***
 dcntrl_+0x877:                  movw   (%rax),%es
 dcntrl_+0x879:                  addl   %eax,(%rax)
 dcntrl_+0x87b:                  addb   %ah,0xf(%rsi)
 dcntrl_+0x87e:                  pushq  %rdi
 dcntrl_+0x87f:                  shlb   $0x13,0xf(%rsi)
 dcntrl_+0x883:                  ***ERROR--unknown op code***
 dcntrl_+0x884:                  movlpd %xmm0,0x8(%rsi)
 dcntrl_+0x889:                  movlpd %xmm0,0x10(%rsi)
 dcntrl_+0x88e:                  movlpd %xmm0,0x18(%rsi)
 dcntrl_+0x893:                  movlpd %xmm0,0x20(%rsi)

Can anyone comment on this situation? This is a binary generated by f95 from 
f77 source code. It seems odd that f95 should generate illegal instructions. 
Maybe this is a Fortran/x86-specific construct unknown to mdb? 

For the ones able to read it, here is the binary dump:

> dcntrl_+86c,100::dump -qfg1
           0  1  2  3  4  5  6  7   8  9  a  b \/  d  e  f
 4477e0:  c0 3b ca 7e 02 33 c0 83  f8 08 7c 4e 8b 85 48 f6
 4477f0:  ff ff 83 c0 f9 0f 0d 8e  00 01 00 00 66 0f 57 c0
 447800:  66 0f 13 06 66 0f 13 46  08 66 0f 13 46 10 66 0f
 447810:  13 46 18 66 0f 13 46 20  66 0f 13 46 28 66 0f 13
 447820:  46 30 66 0f 13 46 38 48  83 c6 40 83 c1 08 3b c8
 447830:  7e c3 3b 8d 48 f6 ff ff  7f 24 66 0f 57 c0 66 90
 447840:  66 0f 13 06 48 83 c6 08  ff c1 3b 8d 48 f6 ff ff
 447850:  7e ee eb 0a c7 05 96 91  5b 00 02 00 00 00 f2 0f
 447860:  2c 05 da 91 5b 00 89 05  58 ba 62 05 83 3d 1d be
 447870:  62 05 00 75 19 48 8d 3d  48 ba 62 05 48 33 c0 e8
 447880:  fc c9 41 00 c7 05 36 ba  62 05 01 00 00 00 83 3d
 447890:  57 b8 9c 05 02 7d 15 66  0f 12 05 91 91 5b 00 66
 4478a0:  0f 13 85 e8 f6 ff ff e9  94 00 00 00 48 63 05 35
 4478b0:  b8 9c 05 48 89 85 b0 f9  ff ff 48 c7 85 d0 f9 ff
 4478c0:  ff 80 1f 93 00 48 8d 85  50 f8 ff ff 48 89 85 d8
 4478d0:  f9 ff ff 48 c7 85 c0 f9  ff ff 30 7a 9d 00 c7 85
 4478e0:  b8 f9 ff ff 00 00 00 00  48 8d bd b0 f9 ff ff 48


Thanks, Manfred
-- 
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to