https://bugs.kde.org/show_bug.cgi?id=406434

Mark Wielaard <m...@klomp.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |m...@klomp.org
             Status|REPORTED                    |CONFIRMED

--- Comment #2 from Mark Wielaard <m...@klomp.org> ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to