[Valgrind-users] Statically linked executables and memcheck

[Joakim S. <ope...@zh...>]

I would like to be able to run memcheck on statically linked binaries,
so I had a look at:
http://valgrind.org/docs/manual/faq.html#faq.hiddenbug

"Second, if your program is statically linked, most Valgrind tools will
only work well if they are able to replace certain functions, such as
malloc, with their own versions. By default, statically linked malloc
functions are not replaced. A key indicator of this is if Memcheck says:

All heap blocks were freed -- no leaks are possible

when you know your program calls malloc. The workaround is to use the
option --soname-synonyms=somalloc=NONE or to avoid statically linking
your program"

I couldn't get it to work so here's a minimal example that illustrates
the problem:

#include <stdlib.h>

int main(void)
{
    int *p = malloc(sizeof(*p));
    *p = 0;
    free(NULL);
    return 0;
}

Compiled without optimization gives:

0000000000400120 <main>:
  400120:       55                      push   %rbp
  400121:       48 89 e5                mov    %rsp,%rbp
  400124:       48 83 ec 10             sub    $0x10,%rsp
  400128:       b8 04 00 00 00          mov    $0x4,%eax
  40012d:       89 c7                   mov    %eax,%edi
  40012f:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%rbp)
  400136:       e8 91 02 00 00          callq  4003cc <malloc>
  40013b:       31 c9                   xor    %ecx,%ecx
  40013d:       89 cf                   mov    %ecx,%edi
  40013f:       48 89 45 f0             mov    %rax,-0x10(%rbp)
  400143:       48 8b 45 f0             mov    -0x10(%rbp),%rax
  400147:       c7 00 00 00 00 00       movl   $0x0,(%rax)
  40014d:       e8 d4 09 00 00          callq  400b26 <free>
  400152:       31 c0                   xor    %eax,%eax
  400154:       48 83 c4 10             add    $0x10,%rsp
  400158:       5d                      pop    %rbp
  400159:       c3                      retq
  40015a:       66 90                   xchg   %ax,%ax

readelf gives us:

Symbol table '.symtab' contains 120 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
...
    78: 0000000000400b26   584 FUNC    GLOBAL DEFAULT    2 free
    79: 00000000004003cc   387 FUNC    GLOBAL DEFAULT    2 malloc
...

And when running valgrind (svn co roughly 10 minutes ago) on it:

==833670== Memcheck, a memory error detector
==833670== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==833670== Using Valgrind-3.11.0.SVN and LibVEX; rerun with -h for copyright info
==833670== Command: ./6.out
==833670==
--833670-- Valgrind options:
--833670--    --soname-synonyms=somalloc=NONE
--833670--    -v
--833670-- Contents of /proc/version:
--833670--   Linux version 3.17.7-gentoo (root@wirbelwind) (gcc version 4.8.3 (Gentoo 4.8.3 p1.1, pie-0.5.9) ) #2 SMP Tue Jan 27 22:22:13 CET 2015
--833670--
--833670-- Arch and hwcaps: AMD64, LittleEndian, amd64-cx16-rdtscp-sse3-avx
--833670-- Page sizes: currently 4096, max supported 4096
--833670-- Valgrind library directory: /home/zhasha/./valgrind/.in_place
--833670-- Reading syms from /home/zhasha/6.out
--833670--    object doesn't have a dynamic symbol table
--833670-- warning: DiCfSI 0x0 .. 0x0 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x1 .. 0x3 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x4 .. 0x9 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0xa .. 0xec outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x0 .. 0x0 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x1 .. 0x3 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x4 .. 0x6 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x7 .. 0x48 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x49 .. 0x49 outside mapped rx segments (NONE)
--833670-- warning: DiCfSI 0x4a .. 0x4c outside mapped rx segments (NONE)
--833670-- Reading syms from /home/zhasha/valgrind/memcheck/memcheck-amd64-linux
--833670--    object doesn't have a dynamic symbol table
--833670-- Scheduler: using generic scheduler lock implementation.
--833670-- Reading suppressions file: /home/zhasha/./valgrind/.in_place/default.supp
==833670== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-833670-by-zhasha-on-???
==833670== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-833670-by-zhasha-on-???
==833670== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-833670-by-zhasha-on-???
==833670==
==833670== TO CONTROL THIS PROCESS USING vgdb (which you probably
==833670== don't want to do, unless you know exactly what you're doing,
==833670== or are doing some strange experiment):
==833670==   /home/zhasha/./valgrind/.in_place/../../bin/vgdb --pid=833670 ...command...
==833670==
==833670== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==833670==   /path/to/gdb ./6.out
==833670== and then give GDB the following command
==833670==   target remote | /home/zhasha/./valgrind/.in_place/../../bin/vgdb --pid=833670
==833670== --pid is optional if only one valgrind process is running
==833670==
==833670==
==833670== HEAP SUMMARY:
==833670==     in use at exit: 0 bytes in 0 blocks
==833670==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==833670==
==833670== All heap blocks were freed -- no leaks are possible
==833670==
==833670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==833670== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Now, as you can see, there's no indication that malloc and free were
hooked. Am I doing something wrong here? This executable is as
un-stripped as possible. Even the libc has debug symbols. I can't get it
working with musl, nor with glibc (where malloc/free seem to be called
__libc_malloc/__cfree).

-- Joakim