But in Clang/LLVM, GlobalValue::VisibilityTypes does not have internal
visibility:
/// An enumeration for the kinds of visibility of global values.
enum VisibilityTypes {
DefaultVisibility = 0, ///< The GV is visible
HiddenVisibility, ///< The GV is hidden
ProtectedVisibility ///< The GV is protected
};
and using -fvisibility=internal in Clang uses the
close-but-not-quite-the-same hidden visibility:
Given that -fvisibility=internal is accepted, I assume this behaviour is
intentional. Can anyone help me understand why that is, or point me to
where I can find out more?
I don’t think there’s any technical reason not to add support for internal visibility. In 2015, I added the alias in clang:
$ git show 7737bd9f9fb5d9cfd5717f36791036fa08d57b95
commit 7737bd9f9fb5d9cfd5717f36791036fa08d57b95
Author: Reid Kleckner <rnk@google.com>
[Driver] Alias -fvisibility=internal to -fvisibility=hidden
The ELF symbol visibilities are:
internal: Not visibile across DSOs, cannot pass address across DSOs
hidden: Not visibile across DSOs, can be called indirectly
default: Usually visible across DSOs, possibly interposable
protected: Visible across DSOs, not interposable
LLVM only supports the latter 3 visibilities. Internal visibility is in
theory useful, as it allows you to assume that the caller is maintaining
a PIC register for you in %ebx, or in some other pre-arranged location.
As far as LLVM is concerned, this isn’t worth the trouble. Using hidden
visibility is always correct, so we can just do that.
Resolves PR9183.
llvm-svn: 250954
While I did say “As far as LLVM is concerned, this isn’t worth the trouble.”, but that was mostly just a reflection of the fact that I filed this bug in 2011 and it never got any attention: https://llvm.org/pr9183.
Given what I know about how PIC code works for PPC, it seems like it might be worth someone’s time to add this visibility mode.