This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Thu, 2017-01-12 at 14:22 +0100, Florian Weimer wrote:
> No, ld links against -lc (in the form of the libc.so script) and notices 
> that the shared object which is being created intends to interpose 
> malloc/free/… because both the object being created and libc.so.6 
> (referenced from libc.so) define these symbols.  To enable that, the 
> symbols are automatically exported.  There is nothing magic about the 
> symbols themselves, it's just how ELF interposition works.
> 
> I don't know if there is a way to disable this from the version script 
> directly, or if there is some other linker script/ld feature to achieve 
> this more directly.

Interesting, thanks.

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.

At least it appears so to me in a quick test... unfortunately I've run
across a different, more serious issue that I've been tracking down so
I haven't been able to 100% verify it.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]