|
From: smiley g. <smi...@ya...> - 2004-09-03 05:10:30
|
Hello valgrind, In reference to Bug 85756: x86 assembly prefix LOCK to guarantee atomicity has no effect http://bugs.kde.org/show_bug.cgi?id=85756 I made the following changes in coregrind/vg_to_ucode.c 3889,3902c3885 < VG_(printf)("LOCK LOCK LOCK LOCK LOCK \n"); < < /* All decode failures end up here. */ < VG_(printf)("disInstr: unhandled instruction bytes: " < "0x%x 0x%x 0x%x 0x%x\n", < (Int)eip_start[0], < (Int)eip_start[1], < (Int)eip_start[2], < (Int)eip_start[3] ); < < /* Print address of failing instruction. */ < VG_(describe_eip)((Addr)eip_start, loc_buf, M_VG_ERRTXT); < VG_(printf)(" lock at %s\n", loc_buf); < --- > /* VG_(printf)("LOCK LOCK LOCK LOCK LOCK \n"); */ When I run my application I found the following in my log files, LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0x93 lock at 0x34D5F61B: get_proc_path (in /lib/tls/libc-2.3.2.so) ==11816== Warning: Addrcheck: ignoring lock request 34D5F619. LOCK LOCK LOCK LOCK LOCK disInstr: unhandled instruction bytes: 0xF0 0xF 0xB1 0xB3 lock at 0x34D96DB3: __GI___libc_freeres (in /lib/tls/libc-2.3.2.so) ==11785== Warning: Addrcheck: ignoring lock request 34D96DAD. Two routines in glibc use lock prefix. My doubts arise as glibc's is substituted with valgrind's own routines still is there minimal dependence on glibc. I have managed to remove all uses of lock prefix from my code, but I still face some problems can this be a reason. Thanks, Madhan. __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |