It turns out the offending opcodes are in what appears to be hand-rolled code in 'm_dispatch/dispatch-ppc32-linux.S', for instance:

        /* VRSAVE save word : 32 bytes */
        mfspr   5,256         /* vrsave reg is spr number 256 */
        stw     5,244(1)

        /* Alignment padding : 4 bytes */

        /* Vector reg save area (quadword aligned) : 192 bytes */
        li      5,224
        stvx    31,5,1
        li      5,208
        stvx    30,5,1
        li      5,192
        stvx    29,5,1
        li      5,176
        stvx    28,5,1
        li      5,160
        stvx    27,5,1
        li      5,144
        stvx    26,5,1
        li      5,128
        stvx    25,5,1
        li      5,112
        stvx    25,5,1
        li      5,96
        stvx    23,5,1
        li      5,80
        stvx    22,5,1
        li      5,64
        stvx    21,5,1
        li      5,48
        stvx    20,5,1

These and the other SIMD instructions in this file make the gcc 4.2.2 PPC assembler choke.

Valgrind works fine on the PPC440GX, which doesn't support Altivec either. Which assembler are you using (as -v </dev/null) ?

as -v:
GNU assembler version 2.17.90-1 (ppc-linux) using BFD version (GNU Binutils) 2.17.90-1.20070806

This PPC Linux version was cross-compiled with the ELDK (Embedded Linux Dev Kit - http://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/).

Freescale's MPC5200 uses an e300 core, while their e600 core is required for Altivec support.  Your Applied Micro PPC440GX seems to be a much nicer chip, and Googling "PPC440gx stvx" turns up enough hits to suggest that the opcode is supported.

I just found another report of this issue on the ELDK site.  I'm off to read (it's a huge page).

Thanks.

I only found that others are currently having the same problem, with no solution.

I found a Freescale publication listing the instruction set of the e300 core (found in the MPC5200) at http://www.freescale.com/files/32bit/doc/ref_manual/e300coreRM.pdf.  "stvx" is not a supported instruction.  I tried a few others like "vand" and "vspltw"... also not supported on the MPC5200.

It seems that 'm_dispatch/dispatch-ppc32-linux.S' is not friendly to non-Altivec cores.

(In reply to comment #3)
> Freescale's MPC5200 uses an e300 core, while their e600 core is required for
> Altivec support.  Your Applied Micro PPC440GX seems to be a much nicer chip,
> and Googling "PPC440gx stvx" turns up enough hits to suggest that the opcode is
> supported.

If you are familiar enough with PPC assembly you can replace the stvx instructions by something that is understood by the e300. Valgrind is an open source project - contributions are welcome.

I diffed "dispatch-ppc32-linux.S" with "dispatch-ppc32-aix5.S".  The latter has four blocks of code commented out with the very helpful notation "// Sigh.  AIX 5.2 has no idea that Altivec exists."  Moving those four changes to the former file allowed a successful build on my non-Altivec target.  (It would appear that the Altivec code is merely saving and restoring the state of the Altivec unit.)

I haven't been able to test the built code yet.  I tried "valgrind ls" and got:

==21128== Memcheck, a memory error detector
==21128== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21128== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21128== Command: ls
==21128==

valgrind:  Fatal error at startup: a function redirection
valgrind:  which is mandatory for this platform-tool combination
valgrind:  cannot be set up.  Details of the redirection are:
valgrind:
valgrind:  A must-be-redirected function
valgrind:  whose name matches the pattern:      strlen
valgrind:  in an object with soname matching:   ld.so.1
valgrind:  was not found whilst processing
valgrind:  symbols from the object with soname: ld.so.1
valgrind:
valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
valgrind:  package on this machine.  (2, longer term): ask the packagers
valgrind:  for your Linux distribution to please in future ship a non-
valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
valgrind:  that exports the above-named function using the standard
valgrind:  calling conventions for this platform.
valgrind:
valgrind:  Cannot continue -- exiting now.  Sorry.


Option (1) isn't available with this distro, so I'm working on (2).

(In reply to comment #6)
> [ ... ]
> valgrind:  Fatal error at startup: a function redirection
> valgrind:  which is mandatory for this platform-tool combination
> valgrind:  cannot be set up.  Details of the redirection are:
> valgrind:
> valgrind:  A must-be-redirected function
> valgrind:  whose name matches the pattern:      strlen
> valgrind:  in an object with soname matching:   ld.so.1
> valgrind:  was not found whilst processing
> valgrind:  symbols from the object with soname: ld.so.1
> valgrind:
> valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
> valgrind:  package on this machine.  (2, longer term): ask the packagers
> valgrind:  for your Linux distribution to please in future ship a non-
> valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
> valgrind:  that exports the above-named function using the standard
> valgrind:  calling conventions for this platform.
> valgrind:
> valgrind:  Cannot continue -- exiting now.  Sorry.
> 
> 
> Option (1) isn't available with this distro, so I'm working on (2).

Regarding option (1): you don't have to copy the debuginfo packages on a local storage medium of the embedded device. Mounting these packages over NFS is also fine.

Thanks, that helped.  I ran the "example" test program from valgrind.org:

============================
#include <stdlib.h>

  void f(void)
  {
     int* x = malloc(10 * sizeof(int));
     x[10] = 0;        // problem 1: heap block overrun
  }                    // problem 2: memory leak -- x not freed

  int main(void)
  {
     f();
     return 0;
  }
============================

... and got the expected output:

============================
==21326== Memcheck, a memory error detector
==21326== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==21326== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==21326== Command: example
==21326==
==21326== Invalid write of size 4
==21326==    at 0x1000045C: f (example.c:6)
==21326==    by 0x1000048F: main (example.c:11)
==21326==  Address 0x4060050 is 0 bytes after a block of size 40 alloc'd
==21326==    at 0xFF5A290: malloc (vg_replace_malloc.c:195)
==21326==    by 0x10000447: f (example.c:5)
==21326==    by 0x1000048F: main (example.c:11)
==21326==
Example program exiting now...
==21326==
==21326== HEAP SUMMARY:
==21326==     in use at exit: 40 bytes in 1 blocks
==21326==   total heap usage: 1 allocs, 0 frees, 40 bytes allocated
==21326==
==21326== LEAK SUMMARY:
==21326==    definitely lost: 40 bytes in 1 blocks
==21326==    indirectly lost: 0 bytes in 0 blocks
==21326==      possibly lost: 0 bytes in 0 blocks
==21326==    still reachable: 0 bytes in 0 blocks
==21326==         suppressed: 0 bytes in 0 blocks
==21326== Rerun with --leak-check=full to see details of leaked memory
==21326==
==21326== For counts of detected and suppressed errors, rerun with: -v
==21326== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 3)
============================

Now to run it on some production code...

Should have been fixed on the trunk in r11173. Please verify.

Closed this issue since no feedback has been received in time.

I have been trying to test the code in the repository.  My target doesn't have autoconf, so I've been getting a cross-compiler configured and figuring out how to do an RPM.  Sorry it's taking too long.

(In reply to comment #11)
> I have been trying to test the code in the repository.  My target doesn't have
> autoconf, so I've been getting a cross-compiler configured and figuring out how
> to do an RPM.  Sorry it's taking too long.

The configure script generated by autogen.sh depends on the autoconf and automake versions but neither on the CPU type nor on the configuration details of the system it has been generated on. So an alternative is to generate the configure script on a system where autotools are available and then copy the configure script to the target system.

Thanks for the suggestion.  Unfortunately, it didn't work for me.  Whether I copied just the "configure" script into a clean copy of the latest repository on the target, or if I ran "autogen.sh" and brought the whole valgrind directory over, I got the error:

> configure: error: cannot find install-sh or install.sh in "." "./.." "./../.."

I am very interested in trying this latest version, because I'm getting a reliable segfault and (seemingly unjustified) buffer warnings in the syscall sendto() in my program.  I'm curious if they would remain with the latest build.

So, I'm back to the cross-compiler and figuring out how to make the package.  It's time I learned.

I can confirm two things:  First, valgrind r11182 cross-compiles without a problem on my Red Hat i386 system; and second, it is better behaved on the target, no longer segfaulting on a particular sendto() call at app launch.  Since I'm cross-compiling this time, I overrode the ac_have_altivec flag, so I don't know if the built-in Altivec test is still failing.  Still, the flag is honored, and the code works fine.

One minor thing, and this could be me: the RPM I built has a bunch of seemingly spurious dependencies (like libc.so.6, which is present in /lib).  One I couldn't explain or satisfy is "rltd(GNU_HASH)".  I installed the RPM on the target with --nodeps, and it seems to be running fine.