On 03/29/2011 10:50 AM, Tom Hughes wrote: > > Messages about starting the tool refer to the point at which the > valgrind launcher execs the tool binary in the valgrind library directory. > > Specifically that error means that the call to execve that the launcher > makes to switch to the tool binary has failed with ENOSYS. I rather > suspect that a system that doesn't implement execve is going to be > sufficiently odd that running valgrind on it will be a major challenge... > > To understand how things work, this is how valgrind starts up: > > - The valgrind launcher (/usr/bin/valgrind) is run. > - The launcher decides which tool you want execs it to > replace the launcher. > - The tool binary loads at a high address then acts as > an ELF loader and loads the target program into the > same process, using LD_PRELOAD to try and inject a > small amount of code into it. > > The launcher is normally dynamically linked, but is just a normal > program and can probably be statically linked if you wish. > > The tool binary is already statically linked and should not need > changing. Only the preload code needs to be added into your program > somehow. >
Running like this (leaving out unnecessary details) seems to work around that issue: VALGRIND_LAUNCHER=memcheck-ppc32-linux memcheck-ppc32-linux a.out Now I see the following error: ==102== ==102== Valgrind's memory management: out of memory: ==102== newSuperblock's request for 4194304 bytes failed. ==102== 25448448 bytes have already been allocated. ==102== Valgrind cannot continue. Sorry. ==102== ==102== There are several possible reasons for this. ==102== - You have some kind of memory limit in place. Look at the ==102== output of 'ulimit -a'. Is there a limit on the size of ==102== virtual memory or address space? ==102== - You have run out of swap space. ==102== - Valgrind has a bug. If you think this is the case or you are ==102== not sure, please let us know and we'll try to fix it. ==102== Please note that programs can take substantially more memory than ==102== normal when running under Valgrind tools, eg. up to twice or ==102== more, depending on the tool. On a 64-bit machine, Valgrind ==102== should be able to make use of up 32GB memory. On a 32-bit ==102== machine, Valgrind should be able to use all the memory available ==102== to a single process, up to 4GB if that's how you have your ==102== kernel configured. Most 32-bit Linux setups allow a maximum of ==102== 3GB per process. ==102== ==102== Whatever the reason, Valgrind cannot continue. Sorry. There should be at least 2GB of memory available. Is there something odd in the way valgrind allocates this memory? thanks, - jason ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
