[PATCH] D65891: [llvm-objcopy] Allow 'protected' visibility to be set when using add-symbol

[Chris Jackson via Phabricator via llvm-commits]

chrisjackson added a comment.

In D65891#1620658 <https://reviews.llvm.org/D65891#1620658>, @MaskRay wrote:

> It makes sense from the perspective of completeness but STV_PROTECTED is problematic and can hardly find a justified use case.
>
> People use STV_PROTECTED when they want to avoid GOT/PLT costs in PIC code. However,
>
> A protected STT_OBJECT prevents you from doing copy relocation. ld.bfd silently accepts this, which can cause ODR violations.
>  A protected STT_FUNC prevents you from making a canonical PLT (-fno-pic code in executable references an external function). If the linker fails to stop you, you'll get pointer equality problems. (It can be argued this case can be fixed by letting the compiler go through GOT when the address of a protected function is taken, but then the GOT indirection will likely break people's expectation. A symbol lookup change is also required on ld.so side.)
>
> I think lld and gold reject both cases. So at the best, a protected symbol can be seen as a promise of the toolchain that the symbol will not be interposed.
>
> Actually, in a DSO, a STV_PROTECTED use case can be easily replaced with the hidden+alias idiom:
>
>   __attribute__((visibility("hidden"))) void internal() {} // internal use
>   __attribute__((alias("internal"))) void external(); // external API
>
>
> The reservation of STV_INTERNAL was requested by SGI when gABI was formulated. All other parties appear to treat STV_INTERNAL the same as STV_HIDDEN.


I agree with your points for standard ELF toolchains. We use STV_PROTECTED in our toolchain, as we have a custom DSO format. The use of protected is not unprecedented, see ARM reference <http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0593a/BEHEHEFC.html> for example.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D65891/new/

https://reviews.llvm.org/D65891