Bug 148363

Summary: vex amd64->IR: unhandled instruction bytes: 0x65 0x4C 0x8B 0x1C (mov %gs:0x10,%r11)
Product: [Developer tools] valgrind Reporter: Mihai DONȚU <mihai.dontu>
Component: vexAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: crash CC: austinenglish
Priority: NOR    
Version: 3.2.3   
Target Milestone: ---   
Platform: Gentoo Packages   
OS: Linux   
Latest Commit: Version Fixed In:
Bug Depends on:    
Bug Blocks: 253451    

Description Mihai DONȚU 2007-07-30 16:50:32 UTC
Version:           3.2.3 (using KDE KDE 3.5.5)
Installed from:    Gentoo Packages
Compiler:          gcc-linux-x86_64 4.1.2 
OS:                Linux

I have a small Win64 emu (much smaller/simpler than wine) which modifies the LDT. Since valgrind (3.2.3) does not support this trickery (amd64?), I wanted to add the support myself. However, more advanced things like:

[...]
vex amd64->IR: unhandled instruction bytes: 0x65 0x4C 0x8B 0x1C
[...]
Illegal opcode at address 0x406459C
    at 0x406459C: ???
    by 0x0: ???
[...]

stand in the way of true happiness :)

$ gdb -c vgcore ./app
$ (gdb) disas 0x000000000406459c 0x0000000004064600
Dump of assembler code from 0x406459c to 0x4064600:
0x000000000406459c:     mov    %gs:0x10,%r11
0x00000000040645a5:     cmp    %r11,%r10

It's in msvcrt.dll (v8.0), DllMain()

I feel this is above my head :)
Comment 1 Mihai DONȚU 2007-07-30 20:57:53 UTC
A small test program:

#include <stdio.h>

int main( void )
{
        __asm__ __volatile__ (
                "movq %%gs:0x10,%%rax"
                :
                :
        );

        return 0;
}

The code above should SIGSEGV because there's no ldt entry for %gs.
Comment 2 Austin English 2014-05-28 00:46:51 UTC
austin@aw25 ~ $ gcc -o foo test.c 
austin@aw25 ~ $ valgrind ./foo 
==18292== Memcheck, a memory error detector
==18292== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==18292== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==18292== Command: ./foo
==18292== 
==18292== Conditional jump or move depends on uninitialised value(s)
==18292==    at 0x40179E4: index (strchr.S:77)
==18292==    by 0x400745D: expand_dynamic_string_token (dl-load.c:425)
==18292==    by 0x400804F: _dl_map_object (dl-load.c:2302)
==18292==    by 0x400138D: map_doit (rtld.c:626)
==18292==    by 0x400E9A3: _dl_catch_error (dl-error.c:187)
==18292==    by 0x4000B30: do_preload (rtld.c:815)
==18292==    by 0x4004122: dl_main (rtld.c:1632)
==18292==    by 0x401529B: _dl_sysdep_start (dl-sysdep.c:249)
==18292==    by 0x4004A4C: _dl_start (rtld.c:331)
==18292==    by 0x40011A7: ??? (in /lib64/ld-2.19.so)
==18292== 
vex amd64->IR: unhandled instruction bytes: 0x65 0x48 0x8B 0x4 0x25 0x10 0x0 0x0
vex amd64->IR:   REX=1 REX.W=1 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==18292== valgrind: Unrecognised instruction at address 0x400501.
==18292==    at 0x400501: main (in /home/austin/foo)
==18292== Your program just tried to execute an instruction that Valgrind
==18292== did not recognise.  There are two possible reasons for this.
==18292== 1. Your program has a bug and erroneously jumped to a non-code
==18292==    location.  If you are running Memcheck and you just saw a
==18292==    warning about a bad jump, it's probably your program's fault.
==18292== 2. The instruction is legitimate but Valgrind doesn't handle it,
==18292==    i.e. it's Valgrind's fault.  If you think this is the case or
==18292==    you are not sure, please let us know and we'll try to fix it.
==18292== Either way, Valgrind will now raise a SIGILL signal which will
==18292== probably kill your program.
==18292== 
==18292== Process terminating with default action of signal 4 (SIGILL)
==18292==  Illegal opcode at address 0x400501
==18292==    at 0x400501: main (in /home/austin/foo)
==18292== 
==18292== HEAP SUMMARY:
==18292==     in use at exit: 0 bytes in 0 blocks
==18292==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==18292== 
==18292== All heap blocks were freed -- no leaks are possible
==18292== 
==18292== For counts of detected and suppressed errors, rerun with: -v
==18292== Use --track-origins=yes to see where uninitialised values come from
==18292== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Illegal instruction
austin@aw25 ~ $ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.8.2/work/gcc-4.8.2/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.2 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.2/include/g++-v4 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.2/python --enable-languages=c,c++,java,go --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --disable-nls --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.8.2 p1.3r1, pie-0.5.8r1' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --disable-libquadmath --enable-lto --without-cloog
Thread model: posix
gcc version 4.8.2 (Gentoo 4.8.2 p1.3r1, pie-0.5.8r1) 
austin@aw25 ~ $ valgrind --version
valgrind-3.9.0