This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: Symbol visibility revised
- To: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Subject: Re: Symbol visibility revised
- From: "H . J . Lu" <hjl at valinux dot com>
- Date: Mon, 1 May 2000 11:03:58 -0700
- Cc: binutils at sourceware dot cygnus dot com, chip at valinux dot com,Ulrich Drepper <drepper at cygnus dot com>
- References: <200005011738.TAA10412@loewis.home.cs.tu-berlin.de>
On Mon, May 01, 2000 at 07:38:18PM +0200, Martin v. Loewis wrote:
> This patch implements some of the symbol visibility aspects in the
> static linker, which my previous patch assumed as the dynamic linker's
> responsibility. It includes the patch Chip sent last month. The
Last time when I tried Chip's patch, the resulting binary in one
of my testcases dumps core. I will take another look at your patch.
> immediate need for this patch is GCC's usage of .hidden as part of the
> new C++ ABI, and the lack for .hidden support in dynamic linkers.
>
> In particular, hidden and internal visibility are implemented using
> the local symbols extension of the versioning feature. The linker
> avoids assigning dynamic indices if possible, or clears them if the
> already have been assigned, setting ELF_LINK_FORCED_LOCAL at the same
> time. Provided that symbol versioning is already available for a
> target, the hidden symbols mechanism should also work on that target.
>
> It would be possible to implement protected visibility in the static
> linker as well, however, that would require changes to the backends
> (specifically, many places that check for ->symbolic || dynindx == -1
> should also check for visibility). Since there is no immediate need
> for supporting .protected, and since that will be most likely added to
> dynamic linkers, anyway, this patch does not attempt to completely
> perform .protected visibility.
>
> As a result, .protected symbols can be overridden from another DSO
> (i.e. they are visible, but not protected). As a special case, PLT
> entries for protected functions are eliminated, so protection works
> for function calls already (based on the -Bsymbolic support in that
> case).
That is incorrect. At our last ABI meeting, we have cleared that
confusion. We decided that the normal symbol resolution shouldn't
be changed due to STV_PROTECTED. That means we cannot do it in the
way of DT_SYMBOLIC. The PLT entry has to be there and the dynamic
linker has to support it.
H.J.