|
From: Michael <mar...@gm...> - 2006-06-30 09:00:11
|
Hi,
we tried the latest valgrind 3.2.0 on an embedded PPC with e500 core, and get
the following error:
/mnt/rd/val-ppc # bin/valgrind /mnt/rd/test_cpp_powerpc
==163== Memcheck, a memory error detector.
==163== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==163== Using LibVEX rev 1606, a library for dynamic binary translation.
==163== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==163== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==163== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==163== For more details, rerun with: -v
==163==
disInstr(ppc): unhandled instruction: 0x7D69C79E
primary 31(0x1F), secondary 1950(0x79E)
==163== valgrind: Unrecognised instruction at address 0x401008C.
...
==163== Process terminating with default action of signal 4 (SIGILL)
==163== Illegal opcode at address 0x401008C
==163== at 0x401008C: __elf_machine_runtime_setup (in /lib/ld-2.3.4.so)
==163== by 0x4002290: _dl_start (in /lib/ld-2.3.4.so)
==163== by 0x400FBA8: _start (in /lib/ld-2.3.4.so)
Did we make a wrong build, or is embedded PPC not supported?
Thanks a lot,
Michael
|
|
From: Julian S. <js...@ac...> - 2006-06-30 11:15:29
|
> disInstr(ppc): unhandled instruction: 0x7D69C79E > primary 31(0x1F), secondary 1950(0x79E) > ==163== valgrind: Unrecognised instruction at address 0x401008C. > ... > ==163== Process terminating with default action of signal 4 (SIGILL) > ==163== Illegal opcode at address 0x401008C > ==163== at 0x401008C: __elf_machine_runtime_setup (in /lib/ld-2.3.4.so) > ==163== by 0x4002290: _dl_start (in /lib/ld-2.3.4.so) > ==163== by 0x400FBA8: _start (in /lib/ld-2.3.4.so) > > Did we make a wrong build, No > or is embedded PPC not supported? Certainly some embedded PPC (PPC440GX?) platforms are known to work. I guess this "e500" has some non standard instructions which are not supported. I can't find out what insn 0x7D69C79E is: sewardj@minnie:~/VgTRUNK/trunk$ ./auxprogs/dump_insn_ppc.sh 0x7D69C79E 0: 7d 69 c7 9e .long 0x7d69c79e Maybe you can use objdump -d on /lib/ld-2.3.4.so and find out what the instruction at 0x401008C is? Or maybe you know info about possible instruction set extensions on e500 ? J |
|
From: AdamB <ada...@ro...> - 2006-07-24 16:40:22
|
Julian Seward <jseward <at> acm.org> writes: > > > > disInstr(ppc): unhandled instruction: 0x7D69C79E > > primary 31(0x1F), secondary 1950(0x79E) > > ==163== valgrind: Unrecognised instruction at address 0x401008C. > > ... > > ==163== Process terminating with default action of signal 4 (SIGILL) > > ==163== Illegal opcode at address 0x401008C > > ==163== at 0x401008C: __elf_machine_runtime_setup (in /lib/ld-2.3.4.so) > > ==163== by 0x4002290: _dl_start (in /lib/ld-2.3.4.so) > > ==163== by 0x400FBA8: _start (in /lib/ld-2.3.4.so) > > > > Did we make a wrong build, > > No > > > or is embedded PPC not supported? > > Certainly some embedded PPC (PPC440GX?) platforms are known to work. > > I guess this "e500" has some non standard instructions which are > not supported. I can't find out what insn 0x7D69C79E is: > > sewardj <at> minnie:~/VgTRUNK/trunk$ ./auxprogs/dump_insn_ppc.sh 0x7D69C79E > 0: 7d 69 c7 9e .long 0x7d69c79e > > Maybe you can use objdump -d on /lib/ld-2.3.4.so and find out what > the instruction at 0x401008C is? Or maybe you know info about > possible instruction set extensions on e500 ? > I'm replying to a slightly old message here as google has just thrown it up and I think it might be related to what I've seen. I've been using valgrind 3.1.0 on an e500 based processor for a while and it works most of the time but has fails with some floating point operations. I normally see the message: Conditional jump or move depends on uninitialised value(s) at 0x4001FA4: _dl_start_final (in /lib/ld-2.3.5.so) by 0x4002754: _dl_start (in /lib/ld-2.3.5.so) by 0x40110D8: _start (in /lib/ld-2.3.5.so) at startup (i haven't suppressed it as I'm not sure of the cause) but after that it will behave normally provided the code contains no floating point operations. The e500 does have some extra instructions as it includes single precision floating point vector and scalar APUs but no double / extended precision APU support (except in the v2 core). It doesn't appear to have an instruction with secondary opcode 1950 though. The floating point operations that do exist on the e500 use the GPRs, not FPRs so would appear to violate valgrind's assumptions that it only needs to track ld / st operations between FPRs and GPRs to know what data has been calculated by floating point operations although I haven't worked out if these instructions are ever being used by gcc. Gcc appears to generate normal floating point operations and rely on a kernel trap handler for floating point instructions. The e500 core manual is available to download from http://www.freescale.com/files/32bit/doc/ref_manual/E500CORERM.pdf |
|
From: Florian B. <eup...@ar...> - 2006-07-28 15:35:27
|
Hi,
I did some more tests regarding the system Michael reported earlier.
I was using a generic PowerPC cross compiler on a x86 to build some
static binaries (to exclude difficulties introduced by libraries).
However valgrind wasn't able to detect most of the "mistakes" found in
the following program:
int main( void )
{
char *p = new char[10];
p[10] = 'a';
return p[0];
}
Valgrind output:
/home/flo/tmp # ./val-ppc/bin/valgrind /mnt/rd/test_cpp_powerpc
==139== Memcheck, a memory error detector.
==139== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==139== Using LibVEX rev 1606, a library for dynamic binary translation.
==139== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==139== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==139== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==139== For more details, rerun with: -v
==139==
==139== Syscall param exit_group(exit_code) contains uninitialised byte(s)
==139== at 0x10010530: _Exit (in /mnt/rd/test_cpp_powerpc)
==139== by 0x100078CC: exit (in /mnt/rd/test_cpp_powerpc)
==139== by 0x10007110: (below main) (in /mnt/rd/test_cpp_powerpc)
==139==
==139== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==139== malloc/free: in use at exit: 0 bytes in 0 blocks.
==139== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==139== For counts of detected errors, rerun with: -v
==139== All heap blocks were freed -- no leaks are possible.
Build system:
flo@escape:~/tmp$ powerpc-linux-g++ --version
powerpc-linux-g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)
Copyright © 2003 Free Software Foundation, Inc.
Dies ist freie Software; die Kopierbedingungen stehen in den Quellen. Es
gibt KEINE Garantie; auch nicht für VERKAUFBARKEIT oder FÜR SPEZIELLE
ZWECKE.
flo@escape:~/tmp$ powerpc-linux-g++ --v
Lese Spezifikationen von /usr/lib/gcc-lib/powerpc-linux/3.3.5/specs
Konfiguriert mit: ../src/configure -v --enable-languages=c,c++
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info
--with-gxx-include-dir=/usr/powerpc-linux/include/c++/3.3
--enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls
--without-included-gettext --enable-clocale=gnu --enable-debug
--disable-multilib --includedir=/usr/powerpc-linux/include
--build=i386-linux --host=i386-linux --target=powerpc-linux
Thread-Modell: posix
gcc-Version 3.3.5 (Debian 1:3.3.5-13)
flo@escape:~/tmp$ uname -a
Linux escape 2.6.16-15-1 #1 Fri Jun 23 10:01:50 CEST 2006 i686 GNU/Linux
Program was built with and without -mcpu=common (No difference for
valgrind output).
target system:
/mnt/rd # uname -a
Linux mpc8548cds 2.6.11 #43 Thu Jun 29 16:13:56 CEST 2006 ppc unknown
MPC8548E (e500 core).
As a side note, an ancient PPC750(G3) works quite well (same test
harness, native valgrind, native g++):
euphoria@schosshund:~/dev/leak_test$ valgrind ./test_cpp
==8782== Memcheck, a memory error detector.
==8782== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==8782== Using LibVEX rev 1606, a library for dynamic binary translation.
==8782== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==8782== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
==8782== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==8782== For more details, rerun with: -v
==8782==
==8782== Invalid write of size 1
==8782== at 0x10000510: main (main.cpp:5)
==8782== Address 0x4027032 is 0 bytes after a block of size 10 alloc'd
==8782== at 0xFFBB558: operator new[](unsigned) (vg_replace_malloc.c:195)
==8782== by 0x100004FC: main (main.cpp:3)
==8782==
==8782== Syscall param exit_group(exit_code) contains uninitialised byte(s)
==8782== at 0xFD6A1D0: _Exit (in /lib/libc-2.3.2.so)
==8782== by 0xFCF334C: exit (in /lib/libc-2.3.2.so)
==8782== by 0xFCDB220: (below main) (in /lib/libc-2.3.2.so)
==8782==
==8782== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 6 from 2)
==8782== malloc/free: in use at exit: 10 bytes in 1 blocks.
==8782== malloc/free: 1 allocs, 0 frees, 10 bytes allocated.
==8782== For counts of detected errors, rerun with: -v
==8782== searching for pointers to 1 not-freed blocks.
==8782== checked 292,392 bytes.
==8782==
==8782== LEAK SUMMARY:
==8782== definitely lost: 10 bytes in 1 blocks.
==8782== possibly lost: 0 bytes in 0 blocks.
==8782== still reachable: 0 bytes in 0 blocks.
==8782== suppressed: 0 bytes in 0 blocks.
==8782== Use --leak-check=full to see details of leaked memory.
Any further suggestions?
Thanks,
Florian
|
|
From: Florian B. <eup...@ar...> - 2006-07-28 15:52:12
|
I forgot to add that the successful test on the PPC750 was done using a 2.4.32 kernel (due to lack of 2.6.x kernel support on nubus-based power macs). Florian |
|
From: Nicholas N. <nj...@cs...> - 2006-07-29 00:47:06
|
On Fri, 28 Jul 2006, Florian Boelstler wrote:
> I did some more tests regarding the system Michael reported earlier.
>
> I was using a generic PowerPC cross compiler on a x86 to build some
> static binaries (to exclude difficulties introduced by libraries).
>
> However valgrind wasn't able to detect most of the "mistakes" found in
> the following program:
>
> int main( void )
> {
> char *p = new char[10];
>
> p[10] = 'a';
>
> return p[0];
> }
>
> Valgrind output:
>
> /home/flo/tmp # ./val-ppc/bin/valgrind /mnt/rd/test_cpp_powerpc
> ==139== Memcheck, a memory error detector.
> ==139== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
> ==139== Using LibVEX rev 1606, a library for dynamic binary translation.
> ==139== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
> ==139== Using valgrind-3.2.0, a dynamic binary instrumentation framework.
> ==139== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
> ==139== For more details, rerun with: -v
> ==139==
> ==139== Syscall param exit_group(exit_code) contains uninitialised byte(s)
> ==139== at 0x10010530: _Exit (in /mnt/rd/test_cpp_powerpc)
> ==139== by 0x100078CC: exit (in /mnt/rd/test_cpp_powerpc)
> ==139== by 0x10007110: (below main) (in /mnt/rd/test_cpp_powerpc)
> ==139==
> ==139== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> ==139== malloc/free: in use at exit: 0 bytes in 0 blocks.
> ==139== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
> ==139== For counts of detected errors, rerun with: -v
> ==139== All heap blocks were freed -- no leaks are possible.
Only thing I can think of is that Valgrind migh not be intercepting and
replacing 'new'. If you run with -v, or -v -v, or -d (I can't remember the
exact incantation) you'll see some stuff about function replacements,
perhaps you can see 'new' being replaced on the machine that works and not
on this machine?
If that's the case, then you have to work out why 'new' is not being
replaced...
Nick
|