Re: [Qemu-devel] [4799] Add instruction counter.

[Blue Swirl]

On 7/11/08, Robert Reif <address@hidden> 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?