This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: gold: Something special about malloc/calloc/realloc/free symbols?
- From: Paul Smith <paul at mad-scientist dot net>
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils <binutils at sourceware dot org>
- Date: Mon, 09 Jan 2017 11:21:16 -0500
- Subject: Re: gold: Something special about malloc/calloc/realloc/free symbols?
- Authentication-results: sourceware.org; auth=none
- References: <1483853481.10278.66.camel@mad-scientist.net> <20170109053133.GX31129@bubble.grove.modra.org>
- Reply-to: paul at mad-scientist dot net
On Mon, 2017-01-09 at 16:01 +1030, Alan Modra wrote:
> > $ nm libmylib.so | grep ' [A-TV-Z] ' | c++filt
> > 0000000000187560 T symbol_one
> > 00000000001862e0 T symbol_two
> > 0000000000166a30 T ...
> > 00000000008907f0 T calloc
> > 0000000000889ba0 T free
> > 000000000088cb80 T malloc
> > 000000000088e0e0 T realloc
> >
> > I don't know why this is. All the other symbols in the source file that
> > defines the above functions are hidden as I expect, but somehow these
> > four magically escape the "local" linker script setting and are
> > published. I've even tried explicitly listing them as local but that
> > didn't help.
> >
> > I'm not sure how that happens, or what I can do about it. Is there some
> > extra __attribute__() setting that can be placed on those symbols so
> > they will ignore my linker script settings?
> >
> > Any thoughts anyone has on next steps would be welcome.
>
> A testcase would be useful. I tried to reproduce the problem you
> describe and my testcase made malloc local as expected.
Yeah. Unfortunately the setup is not easily publishable so I'll need
to try to come up with a self-contained test case.
I was hoping someone had either (a) some immediate thoughts about why
this might be happening, as in some known magical treatment of well-
known heap mgmt methods like this or another __attribute__() that might
be involved, and/or (b) some thoughts on debug steps I could undertake
locally to narrow down the issue.
However, trying to create a test case is the next step.
Thanks...