I think it will be useful to provide very clear linker semantics of the XCOFF visibility
I think that will be helpful, so I’ll attempt to summarize some of the information from the references above here (with some repeats from the thread above) as I understand it.
Summary of XCOFF visibility semantics
Firstly, a symbol for XCOFF doesn’t necessarily have visibility bits. If it doesn’t the AIX linker follows its usual semantics, which is to export no symbols in the dynamic loader section unless the user/toolchain does so by providing an export list containing those symbols to export.
XCOFF supports the following visibility modes, most roughly analogous to the ELF modes with some notable exceptions:
- Symbols are bound at link-edit time, and thus runtime pre-emption is impossible without turning on optional runtime linking.
- The AIX linker appears to observe the visibilities only for place symbols into the exports after resolution, without some of the restrictions of ELF. So a symbol weak and hidden may be over-ridden by an external strong definition.
| Symbol Visibility | Export Semantic |
|---|---|
| Internal | Symbol is not exported. The address of the symbol must not be provided to other programs or shared objects, but the linker does not verify this. |
| Hidden | Symbol is not exported |
| Protected | Symbol is exported but cannot be rebound (or preempted), even if runtime linking is being used. |
| Exported | Symbol is exported with the global export attribute. |
| [None] | The linker takes no action to export the symbol without options and/or export lists |
Current IR Mapping
hidden and protected can be mapped in the natural, direct fashion.
Currently we map default style in the IR to no visibility. As this is the IR assumed default, this provides the typical non-visibility enabled path that users expect.
I am a little bit undecided whether we should let exported take the STV_INTERNAL value from the bitcode format. ModuleSummaryIndex has a visibility field which has just 2 bits, using a value for one purpose will discard others.)
Ah, that’s unfortunate. I agree, it seem to have only accommodated the 4 typical ELF visibilities so if we add exported, we displace internal which may just cause us more problems in the future. Thanks for pointing that out
I guess I’ll try to adjust the implementation to follow the dllexported route for now then, and see how it works out 
It does indeed seems to be the closest match in terms of the semantic of what currently exists in the IR.
FWIW Solaris has
STV_EXPORTED, but its semantic is a bit different.
Yeah, we were speculating if the exported visibility style would be re-usable for that as well. I guess there is a larger question here about such new styles, but hopefully for the moment we can ward off this problem for XCOFF at least by re-using dllexported