Re: gold: Something special about malloc/calloc/realloc/free symbols?

[Cary Coutant <ccoutant at gmail dot com>]

> I noticed in the code that the malloc symbols were being defined in the
> code with __attribute__((visibility("default"))).
>
> When I removed that attribute, then I am able to use the linker script
> to keep my malloc functions private and nm no longer shows them with
> state "T".  I wasn't able to find any output generated by readelf,
> objdump, etc. which showed any difference between symbols marked like
> that and symbols not marked like that (if the object file is compiled
> with -fvisibility=default), but apparently there is one somewhere that
> the linker can see.

No, there's nothing different between using
__attribute__((visibility("default"))) vs. -fvisibility=default.
There's something else going on. It may have to do with versions; in
libc, these symbols are typically marked with a version (e.g.,
"GLIBC_2.2.5"). Try using the linker's -y option to find all
references and definitions of these symbols, then use readelf -s to
see the symbol names with versions.

I think the most reliable way to do this is Florian's suggestion to
use the linker's --wrap option for each of these symbols. That will
translate all references to malloc (for example) into __wrap_malloc,
and references to __real_malloc into malloc. Your versions of these
routines should be named __wrap_malloc, etc. No ld -r is necessary --
just add the necessary --wrap options when you link your shared
library.

(As Florian mentioned earlier, it's really fragile to mix two separate
allocators in one application. You absolutely need to guarantee that
pointers obtained by one malloc are never passed to the other's
realloc or free. If your version is simply some sort of instrumented
malloc, it would be best to have your __wrap_malloc do what it needs
to in the way of instrumentation, but turn around and call
__real_malloc to do the actual allocation.)

-cary