symbol hiding

Dmitry Timoshkov dmitry at baikal.ru
Fri May 14 07:33:25 CDT 2004


"Mike Hearn" <mh at codeweavers.com> wrote:

> > Also, I personally feel a bit not comfortable when someone (for any
> > reason) is looking into a binary and sees names of internal interfaces
> > not appropriate for external learn/use. I find it ugly that I can't fully
> > control such basic things in the ELF world.
> 
> IMHO it's cleaner to do what the glibc team do and simply mark them as
> private using symbol versioning. Yes, they still appear in the symtab, but
> when you read it at least you see:
> 
> __libc_foobar@@GLIBC_PRIVATE
> 
> and there can be no doubt whatsoever that it's internal. That also lets
> you mark things as internal and still use them from other DSOs.

It's even uglier. Instead of resolving the problem that guys decided
just to hide it.

> ELF linker behaviour when there are multiple symbols with the same name is
> defined by the way, it's just a dumb behaviour :) Basically they all
> get linked to the first symbol that was loaded unless you have things like
> -Bsymbolic set (though that only works if the symbol being linked is in
> the same object).

The only thing I can say is that yes, it's really dumb.

> The correct solution to making ELF not suck is to implement support for
> the DT_1_GROUP flag so we can get grouped fixed, like on Solaris. This is
> closer to the Windows model that people intuitively expect. It should also
> help with some of the pathological slowness that prompted initiatives like
> prelink.

Sigh, I still think that ELF is inherently sick, and inventing new (intrusive)
workarounds makes it even worse.

-- 
Dmitry.




More information about the wine-devel mailing list