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

[Paul Smith]

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...