https://bugs.kde.org/show_bug.cgi?id=406434
Philippe Waroquiers <philippe.waroqui...@skynet.be> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |philippe.waroquiers@skynet.
| |be
--- Comment #3 from Philippe Waroquiers <philippe.waroqui...@skynet.be> ---
(In reply to Mark Wielaard from comment #2)
> (In reply to Tom Hughes from comment #1)
> > This is a fundamental, and I believe well documented, limitation.
> >
> > Because valgrind relies on preloading a shared object to do function
> > interception it can't work for a program that doesn't use the dynamic
> > linker, and intercepting malloc calls (among other things) relies on the
> > function interception system.
>
> I don't believe that this is well documented.
> It would at least be helpful if valgrind clearly warned about this.
> For example if there is no PT_INTERP for the executable, but the wrapper
> does use LD_PRELOAD for a vgpreload library.
>
> valgrind doesn't have to do normal ELF symbol interposition. It can
> intercept anything with a symbol name/address. The documentation of
> --soname-synonyms even implies that this would work for statically linked
> code/executables:
>
> ยท Replacements in a statically linked library are done by using
> the NONE pattern. For example, if you link with libtcmalloc.a,
> and only want to intercept the malloc related functions in the
> executable (and standard libraries) themselves, but not any
> other shared libraries, you can give the option
> --soname-synonyms=somalloc=NONE. Note that a NONE pattern will
> match the main executable and any shared library having no
> soname.
>
> But this doesn't work in this case because even if it can see and find the
> malloc related functions in the executable the vgpreload libraries with the
> replacement/interception functions isn't loaded.
>
> In theory we can get the replacements wired in differently like we do with
> add_hardwired_spec () for ld.so. But that would require some way to compile
> in the replacement functions into the tools themselves instead of relying on
> LD_PRELOAD.
Some years ago, I looked at having replacement functions in the tool,
and not as LD_PRELOAD. I think the (only?) (main?) reason why the replacement
functions are in a .so is that they must run in guest mode, and there is
some protection that forbids to run some 'valgrind tool' code in guest mode.
IIRC, if we could separate the 'pages' where we have the 'real valgrind'
code from the 'tool code that must run in client mode', we could have
the same protection but not depend on LD_PRELOAD.
--
You are receiving this mail because:
You are watching all bug changes.
