|
From: Wolfgang R. <wol...@ro...> - 2003-09-04 10:10:19
|
Hello, this happens on a current debian sid system with a binary which used to work well together some months ago. I have an Athlon 1400, and I just recompiled the whole thing with -march=i386 except for external libraries installed as Debian packages. What can I do about this? I would be very time-consuming to reduce the program until the error goes away. Another small programm works correctly. ==11468== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux. ==11468== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. ==11468== Using valgrind-20030725, a program supervision framework for x86-linux . ==11468== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==11468== Startup, with flags: ==11468== --suppressions=/usr/lib/valgrind/default.supp ==11468== -v ==11468== Reading syms from /usr/algo/bin/RUN ==11468== Reading syms from /lib/ld-2.3.2.so ==11468== object doesn't have any debug info ==11468== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so ==11468== Reading syms from /usr/lib/valgrind/valgrind.so ==11468== Reading syms from /lib/libncurses.so.5.3 ==11468== object doesn't have a symbol table ==11468== object doesn't have any debug info ==11468== Reading syms from /usr/lib/debug/libc-2.3.2.so ==11468== Reading suppressions file: /usr/lib/valgrind/default.supp ==11468== Estimated CPU clock rate is 1411 MHz ==11468== disInstr: unhandled instruction bytes: 0x1E 0x7 0xC3 0x8A Wolfgang |
|
From: Tom H. <th...@cy...> - 2003-09-04 11:42:18
|
In message <200...@ro...>
Wolfgang Rohdewald <wol...@ro...> wrote:
> disInstr: unhandled instruction bytes: 0x1E 0x7 0xC3 0x8A
As far as I see 0x1E is "push %ds" which seems very odd - do you have
any idea why your program would want to push a segment register onto
the stack?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: John R.
|
>>disInstr: unhandled instruction bytes: 0x1E 0x7 0xC3 0x8A 1E push %ds 07 pop %es This copies %ds into %es using only two bytes of code, and without overwriting any other register, and with no net change in visible memory. [x86 has no instruction which moves one segment register to another.] Valgrind(memcheck) should recognize it as an idiom. Such a sequence may be used after x86 "string" opcodes (movs, stos, cmps, scans) to restore the default configuration of segment registers. The x86 string opcodes use %es in a special way, and the real question here is why there was no prior complaint about %es being set up-- to be equal to %gs, for instance. This might be used for some thread manipulation, and if so then any movs/stos/cmps/scans would touch different memory locations: the segment base for %es is added to the offset indicated by the operand addressing in the instruction. Valgrind(memcheck) would have to emulate that segment+offset addition in order to track memory state, and this is expensive in time and complexity. The original poster indicated no such complaint, so my guess is that the "push %ds; pop %es" is in a common tail of "if - else" where one branch _does_ change %es, but the actual execution chose the other path which does not write to %es. Probably the coder could move the "push %es; pop %es" out of the common tail and into the appropriate branch, thus "optimizing" the code. It would be even better to avoid changing %es at all, but the LEA opcode deals only with offset (and does not add the segment base), so this would mean that movs/stos/cmps/scans could not be used on thread-local storage that would otherwise use %gs for addressing. The practical effect is that memset() and memcpy() of thread-local storage must not use stos and movs. -- John Reiser, jreiser@BitWagon.com |
|
From: Erik C. <er...@ar...> - 2003-09-04 12:19:02
|
On Thu, Sep 04, 2003 at 12:10:15PM +0200, Wolfgang Rohdewald wrote: > > What can I do about this? I would be very time-consuming to reduce > the program until the error goes away. Another small programm works > correctly. I found a similar problem recently by using the --stop-after flag You do a binary chop search to find the basic block translation that is causing the problem. Valgrind prints out the last translated basic block, so you can look at what it is doing or post it here. If the problem is still there when you use --skin=none then that probably makes for the simplest case. My solution is in http://sourceforge.net/mailarchive/forum.php?thread_id=2835025&forum_id=32038 but if you are compiling all your code with gcc then it's unlikely to be a solution to your problem. -- Erik Corry er...@ar... |
|
From: John R.
|
> this happens on a current debian sid system with a binary which > used to work well together some months ago. > > I have an Athlon 1400, and I just recompiled the whole thing > with -march=i386 except for external libraries installed as Debian > packages. Try "export LD_ASSUME_KERNEL=2.4.1" to tell ld-linux.so.2 to skip over /lib/tls/ when searching for libraraies. The search then starts with /lib/i686/, /lib/mmx/, ..., /lib/ . -- John Reiser, jreiser@BitWagon.com |
|
From: Wolfgang R. <wol...@ro...> - 2003-09-05 02:06:12
|
On 04.09.2003 17:34, John Reiser wrote: > Try "export LD_ASSUME_KERNEL=3D2.4.1" =20 no change. On 04.09.2003 12:10, Nicholas Nethercote wrote: > It's probably because Valgrind now claims (via CPUID) to be a > machine that handles all SSE instructions, when some are missing. > =A0Change VG_(helper_CPUID) in coregrind/vg_helpers.S to the > following (which claims to not support SSE instructions) and > hopefully the problem will be fixed. Does not fix it. On 04.09.2003 14:18, Erik Corry wrote: > If the problem is still there when you use --skin=3Dnone then that > probably makes for the simplest case. yes, it is. On 04.09.2003 14:18, Erik Corry wrote: > I found a similar problem recently by using the --stop-after flag > You do a binary chop search to find the basic block translation > that is causing the problem. =A0Valgrind prints out the last > translated basic block, so you can look at what it is doing or post > it here. I can narrow it to a certain block - however which block it is changes when I do something to the konsole that valgrind runs in. Anyway when disInstr happens, the last block is NOT dumped. It is only dumped when no disInstr occurs. So I cannot find the offending code this way.=20 BTW I downloaded valgrind-20030725.tar.bz2 for making the change in vg_helpers.S and used that changed version for the other tests.=20 So how can I get valgrind to dump the code after disInstr? I believe version 1.0.4 or so still worked for me. How can I get that one out of CVS? Or should I try the latest CVS code? --=20 mit freundlichen Gr=FCssen with my best greetings Wolfgang Rohdewald dipl. Informatik Ing. ETH Rohdewald Systemberatung Karauschenstieg 4 D 21640 Horneburg Tel.: 04163 826 819 Fax: 04163 826 828 Internet: www.rohdewald.de |
|
From: Wolfgang R. <wol...@ro...> - 2003-09-05 09:19:19
|
I found the offending code. This is some 20 year old assembly doing speed optimized BCD arithmetic (written for an 80286). Since I have the same code in C (much slower), I am now using the C code for valgrind, problem solved. This was the assembly code: adj2: addl $0x7,0x8(%ebp) addl $0x7,0xc(%ebp) pushl %ds <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D popl %es <=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ret =20 fcom: pushl %ebp movl %esp,%ebp pushl %edi pushl %esi pushl %ebx call adj2 The last time I did assembly was on Z80 and 6502 (AppleII), so I won't try to change this. Thank you very much for your valuable help! --=20 mit freundlichen Gr=FCssen with my best greetings Wolfgang Rohdewald dipl. Informatik Ing. ETH Rohdewald Systemberatung Karauschenstieg 4 D 21640 Horneburg Tel.: 04163 826 819 Fax: 04163 826 828 Internet: www.rohdewald.de |
|
From: Dan K. <da...@ke...> - 2003-09-05 15:16:29
|
Wolfgang Rohdewald wrote: > I found the offending code. This is some 20 year old assembly > doing speed optimized BCD arithmetic (written for an 80286). > Since I have the same code in C (much slower), I am now using > the C code for valgrind, problem solved. > > This was the assembly code: > > adj2: > addl $0x7,0x8(%ebp) > addl $0x7,0xc(%ebp) > pushl %ds <=================== > popl %es <=================== > ret The push ds, pop es sequence is extremely common, or at least was, back in the day. Valgrind really should support it. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045 |
|
From: Nicholas N. <nj...@ca...> - 2003-10-12 17:57:55
|
On Fri, 5 Sep 2003, Dan Kegel wrote: > > pushl %ds <=================== > > popl %es <=================== > > The push ds, pop es sequence is extremely common, or at least > was, back in the day. Valgrind really should support it. In case it wasn't announced: CVS HEAD does, now, again thanks to Dirk Mueller. N |