elflink.h -Bsymbolic change
H . J . Lu
hjl@lucon.org
Sun Apr 8 15:52:00 GMT 2001
On Sun, Apr 08, 2001 at 02:24:48PM -0700, Ulrich Drepper wrote:
> Hans-Peter Nilsson <hans-peter.nilsson@axis.com> writes:
>
> > if ((h->elf_link_hash_flags & ELF_LINK_HASH_NEEDS_PLT) != 0
> > && eif->info->shared
> > ! && (eif->info->symbolic
> > ! || ELF_ST_VISIBILITY (h->other) == STV_INTERNAL
> > ! || ELF_ST_VISIBILITY (h->other) == STV_HIDDEN)
> > && (h->elf_link_hash_flags & ELF_LINK_HASH_DEF_REGULAR) != 0)
> > {
> > struct elf_backend_data *bed;
>
> This is definitely more correct. Although the STV_INTERNAL might have
Agreed. Alan, did you run "make check" on Linux/ia32 with glibc 2.2?
Your change will cause ELF visibility failures :-). I knew it would
be broken by some changes. That is why I added those tests. But the ELF
protected visibility only works with glibc 2.2. Can we fix it please?
Thanks.
> some processor-specific meaning. But since I'm not aware of any which
> differs from STV_HIDDEN in this respect I think it's fine.
I think it is ok:
STV_INTERNAL
The meaning of this visibility attribute may be defined by
processor supplements to further constrain hidden symbols. A
processor supplement's definition should be such that generic
tools can safely treat internal symbols as hidden.
An internal symbol contained in a relocatable object must be
either removed or converted to STB_LOCAL binding by the
link-editor when the relocatable object is included in an
executable file or shared object.
H.J.
More information about the Binutils
mailing list