I think the GNU linker’s restriction on using GOTOFF for a protected function symbol is because it would be impossible for the dynamic linker to get it right in all possible cases. When the executable references a function of the same name as the protected symbol, there are possibilities the dynamic linker has to distinguish between: 1) the executable’s reference will resolve to the protected function (in which case the reference in the DSO has to be resolved to the executable’s PLT address, just as in the default visibility case); 2) the executable’s reference will resolve to a different function (in which case the reference can be resolved, for example, to the protected function’s load address). Unfortunately at the time of resolving the GOTOFF reference in the DSO, the dynamic linker has no way of choosing between these two possibilities (in particular, it might change in the future, in the presence of dlopen(…,RTLD_DEEPBIND) and so on). So, it seems necessary to disallow references to protected symbols.

As for changing the semantics and preventing the symbol from being overridden, this is desirable in the case that Ulrich describes — he’s trying to minimize the number of dynamic relocations needed, in order to speed startup of large applications with many libraries. His suggested solution using an internal hidden version of the symbol has the same semantics and also cannot be overridden. I guess I’ll ask Ulrich what his concern was with protected symbols.

Ulrich is saying that a protected function symbol is expensive because if a shared library references it without calling it, and if the application also references it without calling it, then both references have to return the same address. I personally don’t think this is worth worrying about, as the dynamic linker can tell, based on the relocation, whether the function is being called or referenced. This means that a reference rather than a call in a shared library is not optimally efficient. But I don’t immediately see why it has to be any more expensive than an ordinary reference to a function in a shared library. In any case, references to functions are not the normal case.

The GNU linker’s restriction on using a GOTOFF reloc for a protected function symbol seems to be an attempt to avoid a bug in getting the address of the function. But it seems to be the wrong approach. It should really be marking the GOT entry with an appropriate reloc so that the dynamic linker can resolve it. I don’t see any reason that that can not work.

So, yes, I think protected function symbols should work fine, and I don’t see any reason to avoid them (modulo toolchain bugs). But I also don’t see them as an optimal solution in general. Making a symbol protected changes the semantics: the symbol can no longer be overriden from outside the shared library. If that is what you want, then fine. But if you want the default semantics, then protected visibility is not helpful.

As for the difference between internal and hidden, I found this discussion:
http://groups.google.com/group/generic-abi/browse_thread/thread/1a84adc15666164
where Jim Dehnert, apparently the SGI representative who originally requested the addition of STV_INTERNAL to the gABI, posts here:
http://groups.google.com/group/generic-abi/browse_thread/thread/2c3c04f556d9b84d
He can’t remember exactly why they needed it, but thinks it was only relevant to link-time (interprocedural) optimization. Everyone else in that discussion (8 authors) says that they treat STV_HIDDEN and STV_INTERNAL identically.

Finally, if you’re not fed up with answering questions about visibility…. In Ulrich Drepper’s DSO how-to:
http://people.redhat.com/drepper/dsohowto.pdf
Drepper says that protected visibility sounds nice but is even more expensive than default visibility. I can’t see why this would be. I see that it would be very tricky if you were allowed use protected function addresses in a non-call way in the DSO. But the gnu toolchain specifically forbids this. Eg:

cmt:~/dso> cat w.c
void prot(void) __attribute__ (( visibility (”protected”) ));
int f(void (*p)(void) )
{
return p==prot;
}

void prot(void)
{
/*nothing*/
}

cmt:~/dso> gcc -fpic -o w.so -shared w.c
/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: /tmp/ccsNpSI0.o: relocation R_386_GOTOFF against protected function `prot’ can not be used when making a shared object
/usr/lib/gcc/i586-suse-linux/4.1.0/../../../../i586-suse-linux/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status

As long as one can deal with this restriction, shouldn’t protected visibility be an optimal solution for both intra-DSO calls (bypassing the dynamic linker and the PLT) and calls and non-call references from outside the DSO (which just use the same mechanisms as they would with default visibility)? Seems like it has just the same effect as Drepper’s suggested:

void __attribute__(( visibility(”default”) )) prot(void)
{
}
extern __typeof(prot) prot_int __attributes__ (( alias(”prot”), visibility(”hidden”) ));

…where you then have to remember to use prot_int when referring to the function from within the DSO. The toolchain does allow to take the address of prot_int for this method, but you do have to be careful since it won’t be same as the address of prot.

On the other hand, I’m reluctant to assume that I know any better than Ulrich Drepper about this stuff — he generally seems to know what he’s talking about so… any thoughts? (I spotted some tricky-looking code in glibc’s elf/dl-lookup.c maybe relating to this, but I don’t really follow it).

I’m done reading up to part 17 of your series, and none of the other sections have puzzled me as much as this whole thing about the meaning of symbol visibilities.

It’s OK to make the address of the function be the address of the PLT entry, what matters is that every reference to the function, no matter where it occurs, get that same address. So there is a two-step process. First, the program linker marks the dynamic symbol in a special way by giving it a non-zero value A, and it also uses A for any relocations which reference the function. The dynamic linker then makes sure to use A for any reference to the function other than actually calling it. That is, in the main executable, A is used for any reloc other than a PLT reloc. And likewise in a shared library (typically the only other reloc would be a GOT reloc). This ensures that every reference to the function, other than calling it, gets the value A. Thus comparisons of the function address for equality will work.

Note that this is not an issue for a function defined in the executable. In that case the dynamic linker will always use the address in the executable for all references to the function. This is also not an issue for a function reference from a shared library. The shared library will naturally have dynamic relocations for the function, and the usual dynamic linker algorithm will ensure that all those relocations refer to the same value.

The problem only arises for a function reference from the main executable. In this case there may not be a dynamic relocation for all references to the function, since the program linker will be able to resolve those relocations to the PLT address. So the special non-zero value in the dynamic symbol table records that there was a reference to the function other than calling it, and it tells the dynamic linker that it must use that address when resolving dynamic relocations in shared libraries other than calling the function.

I hope that makes some sense.

Finally, you’re right, both the program linker and the dynamic linker should treat internal and hidden symbols exactly the same. Explicitly recording both types in the ELF symbol visibility field is just for information. Actually I don’t know of any systems which actually treat internal symbols differently from hidden symbols in any way, though no doubt there are some.

1) I understand why it’s wrong giving the address of the PLT entry when C code takes the address of a function. But you say that the way around this is to specially mark such uses of a function, with a special symbol that has the value of the address of the PLT entry. Isn’t this the same thing? I’m obviously not following that paragraph properly.

2) What possible difference can it make to the linker whether a symbol is marked STV_INTERNAL vs STV_HIDDEN? I can understand that the compiler might be able to do some optimizations if it knows that the function will never be called from outside the executable/shared lib — maybe can avoid loading the PIC register since you know it’s already done by the caller. But that’s the compiler: why would the linker need to know the difference between internal and hidden?

Thanks for some interesting articles.