|
From: Daniel M. <im...@im...> - 2012-01-23 20:25:55
|
Hi list,
whenever i want to memcheck a 32bit program on my 64bit system i receive the following
message:
vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40
==16815== valgrind: Unrecognised instruction at address 0x44143d0.
==16815== at 0x44143D0: _dl_sysdep_start (dl-sysdep.c:160)
==16815== by 0x4404C47: _dl_start (rtld.c:336)
==16815== by 0x4401096: ??? (in /lib32/ld-2.13.so)
the line (1 line context) reads:
case AT_HWCAP:
GLRO(dl_hwcap) = (unsigned long int) av->a_un.a_val;
break;
i wanted to check exactly which instruction it is by using objdump -M i386 on said file
but that won#t even come close to said address.
any pointers on how to provide more useful information?
cheers
--
Mierswa, Daniel
If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do.
--- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22
|
|
From: John R. <jr...@bi...> - 2012-01-23 20:46:30
|
> whenever i want to memcheck a 32bit program on my 64bit system i receive the following > message: > > vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x40 > ==16815== valgrind: Unrecognised instruction at address 0x44143d0. > ==16815== at 0x44143D0: _dl_sysdep_start (dl-sysdep.c:160) > ==16815== by 0x4404C47: _dl_start (rtld.c:336) > ==16815== by 0x4401096: ??? (in /lib32/ld-2.13.so) $ gdb /lib32/ld-2.13.so (gdb) disassem _dl_sysdep_start and then perhaps do some matching on the low 12 bits (0xFFF) of the address: 0x44143D0 ==> any address ending in 0x3D0. In 32-bit mode, hardware opcode 0xC5 is 'LDS' (Load Data Segment register), which compiled software does not use. -- |
|
From: Daniel M. <im...@im...> - 2012-01-23 21:03:55
|
On 23.01.2012 21:46, John Reiser wrote:
> and then perhaps do some matching on the low 12 bits (0xFFF) of the address:
> 0x44143D0 ==> any address ending in 0x3D0.
0x000143d0 <+880>: vmovd 0x4(%eax),%xmm0
> In 32-bit mode, hardware opcode 0xC5 is 'LDS' (Load Data Segment register),
> which compiled software does not use.
what exactly does that mean now regarding my problem? is glibc broken? valgrind? :D
thanks for the quick reply
--
Mierswa, Daniel
If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do.
--- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22
|
|
From: Tom H. <to...@co...> - 2012-01-23 21:17:16
|
On 23/01/12 21:02, Daniel Mierswa wrote: > On 23.01.2012 21:46, John Reiser wrote: >> and then perhaps do some matching on the low 12 bits (0xFFF) of the address: >> 0x44143D0 ==> any address ending in 0x3D0. > 0x000143d0<+880>: vmovd 0x4(%eax),%xmm0 Well that is an AVX instruction, but I thought they were only valid in 64 bit mode as 0xC5 is (as John said) LDS in 32 bit mode. In 64 bit mode it is a VEX prefix for an AVX instruction. Details on the work to add AVX support to valgrind can be found in the bug tracker: https://bugs.kde.org/show_bug.cgi?id=273475 Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Daniel M. <im...@im...> - 2012-01-23 21:32:25
|
On 23.01.2012 22:16, Tom Hughes wrote: > Well that is an AVX instruction, but I thought they were only valid in 64 bit mode as 0xC5 is (as John said) LDS in 32 bit mode. In 64 bit mode it is a VEX prefix for an AVX instruction. Ok interesting. Does that mean my gcc produces bad code or is your assumption wrong or something else? :P > Details on the work to add AVX support to valgrind can be found in the bug tracker: https://bugs.kde.org/show_bug.cgi?id=273475 Hm doesn't seem to get much attention since early october last year. :/ -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22 |
|
From: John R. <jr...@bi...> - 2012-01-23 21:59:13
|
On 01/23/2012 01:02 PM, Daniel Mierswa wrote: > On 23.01.2012 21:46, John Reiser wrote: >> and then perhaps do some matching on the low 12 bits (0xFFF) of the address: >> 0x44143D0 ==> any address ending in 0x3D0. > 0x000143d0 <+880>: vmovd 0x4(%eax),%xmm0 >> In 32-bit mode, hardware opcode 0xC5 is 'LDS' (Load Data Segment register), >> which compiled software does not use. > what exactly does that mean now regarding my problem? is glibc broken? valgrind? :D Probably there is an unexpected interaction between the code in glibc which does processor detection using CPUID (etc.), and the code in valgrind which delivers "synthetic" results for CPUID. Both valgrind and glibc might need to be more robust. Look in the disassembly for 'cpuid'. File a bug report against valgrind at https://bugs.kde.org/ . Include the complete disassembly of _dl_sysdep_start, and the name and version of your Linux and glibc. -- |
|
From: Daniel M. <im...@im...> - 2012-01-23 22:51:15
|
On 23.01.2012 22:59, John Reiser wrote: > Probably there is an unexpected interaction between the code in glibc > which does processor detection using CPUID (etc.), and the code in > valgrind which delivers "synthetic" results for CPUID. Both valgrind > and glibc might need to be more robust. I just compiled glibc with -mno-avx and tried to shoot valgrind again. Now libstdc++ turns out to be the problem: vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x44 ==2297== valgrind: Unrecognised instruction at address 0x5358a90. ==2297== at 0x5358A90: std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::_M_sync(char*, unsigned int, unsigned int) (in /usr/lib32/libstdc++.so.6.0.16) > Look in the disassembly for 'cpuid'. File a bug report against valgrind > at https://bugs.kde.org/ . Include the complete disassembly of > _dl_sysdep_start, and the name and version of your Linux and glibc. The _dl_sysdep_start dump does not contain cpuid. However, ld.so does: $ objdump /usr/lib64/debug/lib32/ld-2.13.so.debug -D | grep cpuid 23092: 0f a2 cpuid 35b4c: 0f a2 cpuid Bug report: https://bugs.kde.org/show_bug.cgi?id=292300 -- Mierswa, Daniel If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do. --- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22 |
|
From: Tom H. <to...@co...> - 2012-01-24 00:39:35
|
On 23/01/12 21:31, Daniel Mierswa wrote: > On 23.01.2012 22:16, Tom Hughes wrote: >> Well that is an AVX instruction, but I thought they were only valid in 64 bit mode as 0xC5 is (as John said) LDS in 32 bit mode. In 64 bit mode it is a VEX prefix for an AVX instruction. > Ok interesting. Does that mean my gcc produces bad code or is your assumption wrong or something else? :P Further investigation suggests that AVX instructions are valid in 32 bit mode and the VEX prefix encoding has been carefully arranged so that valid prefixes cannot be mistaken for valid LDS instructions. See http://aceshardware.freeforums.org/intel-avx-kills-amd-sse5-t538.html for more details. So you are just seeing the lack of AVX support. >> Details on the work to add AVX support to valgrind can be found in the bug tracker: https://bugs.kde.org/show_bug.cgi?id=273475 > Hm doesn't seem to get much attention since early october last year. :/ Actually Julian merged some of the preliminary work to restructure the instruction decoder back to trunk the other day. Tom -- Tom Hughes (to...@co...) http://compton.nu/ |
|
From: Daniel M. <im...@im...> - 2012-01-24 01:23:15
|
On 24.01.2012 01:39, Tom Hughes wrote:
> So you are just seeing the lack of AVX support.
phew kind of relieved, i thought my compiler is playing tricks on me :)
--
Mierswa, Daniel
If you still don't like it, that's ok: that's why I'm boss. I simply know better than you do.
--- Linus Torvalds, comp.os.linux.advocacy, 1996/07/22
|