From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KHLhL-0005KI-VO for qemu-devel@nongnu.org; Fri, 11 Jul 2008 12:42:20 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KHLhK-0005JY-CX for qemu-devel@nongnu.org; Fri, 11 Jul 2008 12:42:19 -0400 Received: from [199.232.76.173] (port=60254 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KHLhK-0005JO-3I for qemu-devel@nongnu.org; Fri, 11 Jul 2008 12:42:18 -0400 Received: from an-out-0708.google.com ([209.85.132.248]:54478) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KHLhJ-000524-Jg for qemu-devel@nongnu.org; Fri, 11 Jul 2008 12:42:18 -0400 Received: by an-out-0708.google.com with SMTP id d18so1274118and.130 for ; Fri, 11 Jul 2008 09:42:15 -0700 (PDT) Message-ID: Date: Fri, 11 Jul 2008 19:42:15 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] [4799] Add instruction counter. In-Reply-To: <4876957D.9030502@earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <4876957D.9030502@earthlink.net> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On 7/11/08, Robert Reif wrote: > Paul Brook wrote: > > > Revision: 4799 > > > http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=4799 > > Author: pbrook > > Date: 2008-06-29 01:03:05 +0000 (Sun, 29 Jun 2008) > > > > Log Message: > > ----------- > > Add instruction counter. > > > > > > > This patch breaks sparc32 for me. > > A bisection shows: > > 4798 works > 4799 doesn't build > 4800 doesn't work (crashes with illegal instruction) > > running qemu-g in sparc-test produces: > > ./qemu-g: line 4: 9859 Illegal instruction qemu-system-sparc -kernel > vmlinux-2.6.11+tcx -initrd linux.img -append "root=/dev/ram" > > running under valgrind produces this: > > valgrind --trace-children=yes qemu-system-sparc -kernel vmlinux-2.6.11+tcx > -initrd linux.img -append "root=/dev/ram" > ==9861== Memcheck, a memory error detector. > ==9861== Copyright (C) 2002-2008, and GNU GPL'd, by Julian Seward et al. > ==9861== Using LibVEX rev 1806, a library for dynamic binary translation. > ==9861== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. > ==9861== Using valgrind-3.4.0.SVN, a dynamic binary instrumentation > framework. > ==9861== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. > ==9861== For more details, rerun with: -v > ==9861== > ==9861== Warning: set address range perms: large range 144179200 > (undefined) > vex x86->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF > vex x86->IR: unhandled instruction bytes: 0xFF 0xFF 0xFF 0xFF > ==9861== valgrind: Unrecognised instruction at address 0x114BA050. > ==9861== Your program just tried to execute an instruction that Valgrind > ==9861== did not recognise. There are two possible reasons for this. > ==9861== 1. Your program has a bug and erroneously jumped to a non-code > ==9861== location. If you are running Memcheck and you just saw a > ==9861== warning about a bad jump, it's probably your program's fault. > ==9861== 2. The instruction is legitimate but Valgrind doesn't handle it, > ==9861== i.e. it's Valgrind's fault. If you think this is the case or > ==9861== you are not sure, please let us know and we'll try to fix it. > ==9861== Either way, Valgrind will now raise a SIGILL signal which will > ==9861== probably kill your program. > ==9861== > ==9861== Process terminating with default action of signal 4 (SIGILL) > ==9861== Illegal opcode at address 0x114BA050 > ==9861== at 0x114BA050: ??? > ==9861== > > This is on a RedHat 9 system: > > uname -a > Linux dell 2.4.20-31.9smp #1 SMP Tue Apr 13 17:40:10 EDT 2004 i686 i686 > i386 GNU/Linux > > gcc --version > gcc (GCC) 3.2.2 20030222 (Red Hat Linux 3.2.2-5) I can't reproduce the problem, with valgrind or without. I also tried recompiling with different gccs but still everything works fine. I have retired all real i386 machines so my tests were run inside an i386 chroot on an amd64 system, maybe that causes problems. Does anyone else see this error?