|
From: Tom H. <to...@co...> - 2011-03-29 15:50:22
|
On 29/03/11 16:25, Jason Kraftcheck wrote:
> On 03/29/2011 10:13 AM, Tom Hughes wrote:
>> On 29/03/11 15:33, Jason Kraftcheck wrote:
>>
>>> Can anyone offer any suggestions about how to use valgrind in an environment
>>> which doesn't support shared libraries? I could staticly link the valgrind
>>> components into my program but it isn't clear how to handle initialization,
>>> startup, etc. The first problem will be the multiple main routines.
>>
>> Well valgrind is mostly static - the only place it uses shared libraries
>> is to inject it's malloc etc replacements into your programs.
>>
>> If you really want to do this, it is only the code from the various
>> vgpreload*.so libraries that you need to link into your program. You
>> should then still be able to use valgrind in the normal way.
>>
>
> I tried that but I get errors like:
>
> valgrind: failed to start tool 'memcheck' for platform 'ppc32-linux':
> Function not implemented
>
> Is there something I can specify for --tool= to tell valgrind not to try to
> load anything (because I've already statically linked coregrind and memcheck)?
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.
Tom
--
Tom Hughes (to...@co...)
http://compton.nu/
|