|
From: Lionel U. <lio...@fr...> - 2006-03-30 20:51:24
|
Hi all,
To test some stuff I wanted to run valgrind-ppc on a QEMU image running on
my X86 box (it will be really slow, but well, it's just to do some 'proof of
concept' stuff).
Anyway, I had first the issue that I was not able to build the Valgrind
(3.1.1) version out of the box due to the fact that 'as' was barfing on the
Altivec test (in m_machine.c) because QEMU only emulates a G3 (/proc/cpuinfo
tells '604' as CPU).
After forcing it to FALSE I was able to build Valgrind (on the box itself -
an emulated Debian Sarge).
The problem is that when I start valgrind, I get this:
debian-ppc32:~# valgrind /bin/ls
==584== Memcheck, a memory error detector.
==584== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==584== Using LibVEX rev 1575, a library for dynamic binary translation.
==584== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==584== Using valgrind-3.1.1, a dynamic binary instrumentation framework.
==584== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==584== For more details, rerun with: -v
==584==
==584==
==584== Process terminating with default action of signal 4 (SIGILL)
==584== Illegal opcode at address 0x7005F36C
==584== at 0x400F6C4: (within /lib/ld-2.3.2.so)
==584==
==584== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==584== malloc/free: in use at exit: 0 bytes in 0 blocks.
==584== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==584== For counts of detected errors, rerun with: -v
==584== All heap blocks were freed -- no leaks are possible.
Illegal instruction
So now I have a dilemna: where is the bug - in QEMU or in Valgrind :-) ?
Does anyone know how I could progress further on this ?
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
|
|
From: Julian S. <js...@ac...> - 2006-03-30 21:56:38
|
> Anyway, I had first the issue that I was not able to build the Valgrind > (3.1.1) version out of the box due to the fact that 'as' was barfing on the > Altivec test (in m_machine.c) because QEMU only emulates a G3 > (/proc/cpuinfo tells '604' as CPU). Hmm. V should be able to run even on low-end PPCs. Something funny about the configure test, maybe? > ==584== at 0x400F6C4: (within /lib/ld-2.3.2.so) My guess is that you're getting this on the dispatch code in coregrind/m_dispatch/dispatch-ppc32-linux.S. That could either be due to a bug in Valgrind, an unimplemented instruction in QEMU, or an old 2.4 kernel with buggy signal handling on ppc. Try this: export VALGRIND_LAUNCHER= # can be anything, just needs to be set gdb $prefix/lib/valgrind/ppc32-linux/none run ls -l # you're now running valgrind on gdb # sigill happens where Note, if you get any sigsegvs before the sigill, just tell gdb to continue - they are normal. J |
|
From: Lionel U. <lio...@fr...> - 2006-04-01 14:51:28
|
> Hmm. V should be able to run even on low-end PPCs. Something funny
> about the configure test, maybe?
Well when you check the code in coregrind/m_machine.c you have the following:
tmp_act.ksa_handler = handler_sigill;
VG_(sigaction)(VKI_SIGILL, &tmp_act, NULL);
have_vmx = True;
if (__builtin_setjmp(env_sigill)) {
have_vmx = False;
} else {
__asm__ __volatile__("vor 0,0,0");
}
This is not protected by any configure check. And it seems (according to
some discussion I had with a guy on the #QEMU IRC channel) that GNU 'as'
does not accept any instructions that the CPU it is being running on would
not support.
I did the following check on my virtual machine:
debian-ppc32:~# cat test.c
void foo(void) {
__asm__ __volatile__("vor 0,0,0");
}
debian-ppc32:~# gcc -c ./test.c
/tmp/ccRnXeri.s: Assembler messages:
/tmp/ccRnXeri.s:11: Error: Unrecognized opcode: vor'
debian-ppc32:~# gcc --version
gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
debian-ppc32:~# as --version
GNU assembler 2.15
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License. This program has absolutely no warranty.
This assembler was configured for a target of powerpc-linux'.
As Valgrind's code is correct (i.e. it catches the exception when the
instruction is not present) I have no idea how to 'force' the assembler to
accept this operand...
>
> > ==584== at 0x400F6C4: (within /lib/ld-2.3.2.so)
>
> My guess is that you're getting this on the dispatch code in
> coregrind/m_dispatch/dispatch-ppc32-linux.S. That could either be
> due to a bug in Valgrind, an unimplemented instruction in QEMU,
> or an old 2.4 kernel with buggy signal handling on ppc.
debian-ppc32:~# uname -a
Linux debian-ppc32 2.4.27.001 #1 Sat Oct 17 00:40:12 EET 1970 ppc GNU/Linux
So it does not seem to be such an old 2.4 kernel.
> Try this:
>
> export VALGRIND_LAUNCHER=
> # can be anything, just needs to be set
>
> gdb $prefix/lib/valgrind/ppc32-linux/none
> run ls -l
> # you're now running valgrind on gdb
> # sigill happens
> where
>
> Note, if you get any sigsegvs before the sigill, just tell gdb
> to continue - they are normal.
I tried what you wanted ... but it managed to crash QEMU with the following
error message:
qemu: fatal: Trace exception is not implemented yet !
I will try to see on the QEMU lists how to get around this...
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
|
|
From: Julian S. <js...@ac...> - 2006-04-04 03:21:43
|
> To test some stuff I wanted to run valgrind-ppc on a QEMU image running on
> my X86 box (it will be really slow, but well, it's just to do some 'proof
> of concept' stuff).
Ok. I finally managed to get the QEMU image working and reproduced
the problem on the trunk (3.2 line), then fixed it (r5820). It now
runs ok on 'debian-ppc32'.
I suggest what you do is throw away your hacked 3.1.1, start with a
clean 3.1.1 tree, apply the attached patch, and try again. It should
work. Patch might not apply cleanly to 3.1.1, but you can easily
enough figure out what you need to change in m_machine.c.
J
Modified: trunk/coregrind/m_machine.c
===================================================================
--- trunk/coregrind/m_machine.c 2006-04-03 16:38:33 UTC (rev 5819)
+++ trunk/coregrind/m_machine.c 2006-04-04 03:08:49 UTC (rev 5820)
@@ -380,7 +380,7 @@
if (__builtin_setjmp(env_sigill)) {
have_V = False;
} else {
- __asm__ __volatile__("vor 0,0,0");
+ __asm__ __volatile__(".long 0x10000484"); /*vor 0,0,0*/
}
/* General-Purpose optional (fsqrt, fsqrts) */
|
|
From: Lionel U. <lio...@fr...> - 2006-04-15 13:54:12
|
> I suggest what you do is throw away your hacked 3.1.1, start with a
> clean 3.1.1 tree, apply the attached patch, and try again. It should
> work. Patch might not apply cleanly to 3.1.1, but you can easily
> enough figure out what you need to change in m_machine.c.
Well did that change and now it builds fine out of the box. But I still have
the same problem I reported when starting Valgrind on any executable.
So I start to wonder if it's not my build of QEMU that is the problem as we
are using exactly the same disk image for Linux-PPC.
Could you put somewhere your 'qemu-system-ppc' binary that I try it on my
box to see if works better ?
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
|
|
From: Julian S. <js...@ac...> - 2006-04-15 18:58:15
|
> Could you put somewhere your 'qemu-system-ppc' binary that I try it on my > box to see if works better ? Could be difficult considering it has some strange .so paths linked into it. In any case you can't move an QEMU install to another path; it doesn't work (I tried). It is just a plain build of qemu from cvs on x86, using gcc-3.4.3 and configured like this ./configure --prefix=... --target-list=i386-softmmu,x86_64-softmmu,ppc-softmmu J |