<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> SYM_V_UNSPECIFIED has no corresponding visibility bit on ELF<br> SYM_V_INTERNAL ~= STV_INTERNAL<br> SYM_V_HIDDEN ~= STV_INTERNAL<br> SYM_V_PROTECTED ~= STV_PROTECTED<br> SYM_V_EXPORTED ~= STV_DEFAULT</blockquote><div><br></div><div>These mappings are mostly right.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If a symbol is marked __attribute__((visibility("default"))) in the<br>source code, it will get the SYM_V_EXPORTED bit and <strike>cannot be restricted<br>by an exportlist (like a GNU version script).</strike></blockquote><div>Exportlist could still override them in some scenarios. But in some cases, it could result in errors reported by the linker.</div><div>The mixed use of export list and visibility attribute could bring confusion in code development, and therefore is generally not recommended.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">The main purpose of -fnovisibility is to ignore __attribute__((visibility("default"))),<br>so that such a symbol can still be restricted by an exportlist.<br></blockquote><div> The main purpose of the option is to get the default behavior to be consistent with other compilers on AIX (xlclang and gcc), </div><div>which is no visibility is set on the symbol even when attribute is presented. </div><div>Users could use the export list to control the symbol visibility. If no export list is present, no symbol is exported.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 15, 2020 at 6:42 PM Fāng-ruì Sòng <<a href="mailto:maskray@google.com">maskray@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 2020-09-15, Jason Liu wrote:<br>
>> What is ultimately the behavior for "unspecified" symbols, when no<br>
>export-list is provided by the user?<br>
><br>
>If symbols have `unspecified` visibility, and no export list is provided,<br>
>symbols will not get exported.<br>
><br>
>> Are you saying that on the existing AIX compilers/linkers, the<br>
>export-list cannot be used to make a symbol "hidden" (non-exported), if it<br>
>had been explicitly annotated visibility("default") in the source (assuming<br>
>visibility declarations weren't being ignored)? That only "unspecified"<br>
>symbols can be modified by the export-list?<br>
><br>
>The export list is able to override the visibility settings in the object<br>
>file in some situations, but not in all situations. The scenario you<br>
>described above could be overridden by export list.<br>
>There is a comprehensive list for all scenarios here:<br>
><a href="https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html" rel="noreferrer" target="_blank">https://www.ibm.com/developerworks/aix/library/au-aix-symbol-visibility-part2/index.html</a><br>
>in<br>
>Table 1.<br>
><br>
>Again, this is more for getting the default right on AIX. GCC and xlclang<br>
>on AIX have the consistent default behavior as what we described for<br>
>-mignore-xcoff-visibility.<br>
<br>
Hi Jason, am I right for the following points?<br>
<br>
The AIX/XCOFF visibility properties are roughly:<br>
<br>
SYM_V_UNSPECIFIED has no corresponding visibility bit on ELF<br>
SYM_V_INTERNAL ~= STV_INTERNAL<br>
SYM_V_HIDDEN ~= STV_INTERNAL<br>
SYM_V_PROTECTED ~= STV_PROTECTED<br>
SYM_V_EXPORTED ~= STV_DEFAULT<br>
<br>
If a symbol is marked __attribute__((visibility("default"))) in the<br>
source code, it will get the SYM_V_EXPORTED bit and cannot be restricted<br>
by an exportlist (like a GNU version script).<br>
<br>
The main purpose of -fnovisibility is to ignore __attribute__((visibility("default"))),<br>
so that such a symbol can still be restricted by an exportlist.<br>
<br>
>On Tue, Sep 15, 2020 at 5:20 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>> wrote:<br>
><br>
>> On Tue, Sep 15, 2020 at 3:29 PM Jason Liu via cfe-dev <<br>
>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>>> > I remain unclear as to how that is a useful or important feature. Are<br>
>>> you worried about compatibility with code which incorrectly specified<br>
>>> visibility("hidden"), when it actually did need to export the symbol?<br>
>>><br>
>>> I guess I understand the point of confusion, so I will try to clarify it<br>
>>> a little bit.<br>
>>> It goes back to Clang does not have "unspecified" visibility mapping yet.<br>
>>> On AIX, the baseline visibility is not "default" or export. The baseline<br>
>>> visibility is "unspecified" when no attribute is marked on the symbol.<br>
>>><br>
>><br>
>> What is ultimately the behavior for "unspecified" symbols, when no<br>
>> export-list is provided by the user?<br>
>><br>
>> And -mignore-xcoff-visibility means let all the symbols have "unspecified"<br>
>>> visibility, whether or not any visibility attribute is specified on the<br>
>>> symbol. So that user could use export list in the link step to control the<br>
>>> visibility on AIX, which gives a more fine-grained control.<br>
>>><br>
>><br>
>> On GNU/ELF, the export-list functionality (called version-script there)<br>
>> allows you to remove symbols from the list to be exported, but not add<br>
>> them. So, visibility("default") marks it as potentially-exported, but the<br>
>> version-script can override and make the symbol hidden if it wants to.<br>
>><br>
>> Are you saying that on the existing AIX compilers/linkers, the export-list<br>
>> cannot be used to make a symbol "hidden" (non-exported), if it had been<br>
>> explicitly annotated visibility("default") in the source (assuming<br>
>> visibility declarations weren't being ignored)? That only "unspecified"<br>
>> symbols can be modified by the export-list?<br>
>><br>
>><br>
>><br>
>>> As it is right now, the llc on AIX actually treats<br>
>>> `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline<br>
>>> visibility mode on AIX. So it is a bit messy there, and we will need to<br>
>>> clean that up when we add "unspecified" visibility attribute to clang for<br>
>>> AIX. But I don't think it should prevent us from making the default<br>
>>> behavior(unspecified visibility for all symbols) right on AIX for now.<br>
>>> Hope that would clean up the confusion.<br>
>>><br>
>>><br>
>>> On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>><br>
>>>> On Tue, Sep 15, 2020 at 11:21 AM James Y Knight via cfe-dev<br>
>>>> <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>> ><br>
>>>> > On Fri, Sep 11, 2020 at 3:55 PM Hubert Tong <<br>
>>>> <a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>>>> >><br>
>>>> >> On Fri, Sep 11, 2020 at 2:58 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>><br>
>>>> wrote:<br>
>>>> >>><br>
>>>> >>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <<br>
>>>> <a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>>>> >>>><br>
>>>> >>>> On Thu, Sep 10, 2020 at 9:07 PM James Y Knight <<a href="mailto:jyknight@google.com" target="_blank">jyknight@google.com</a>><br>
>>>> wrote:<br>
>>>> >>>>><br>
>>>> >>>>><br>
>>>> >>>>><br>
>>>> >>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <<br>
>>>> <a href="mailto:hubert.reinterpretcast@gmail.com" target="_blank">hubert.reinterpretcast@gmail.com</a>> wrote:<br>
>>>> >>>>>><br>
>>>> >>>>>> On Thu, Sep 10, 2020 at 6:30 PM James Y Knight via cfe-dev <<br>
>>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br>
>>>> >>>>>>><br>
>>>> >>>>>>> But why does AIX want to ignore visibility restrictions encoded<br>
>>>> via attribute? Especially by default?<br>
>>>> >>>>>><br>
>>>> >>>>>> One reason is that AIX performs more early/less lazy symbol<br>
>>>> resolution (even with runtime linking) than, say, Linux. So, if a project<br>
>>>> goes with an export-by-default model (via attribute in some scope), they<br>
>>>> can cause link-time errors from symbol references to undefined symbols from<br>
>>>> code that would otherwise have been discarded as unreferenced by the<br>
>>>> linker. It seems such code is not uncommon (and has the questionable effect<br>
>>>> of exporting template instantiations based on "client provided" types that<br>
>>>> are not part of the "library"/"utility" code in question).<br>
>>>> >>>>><br>
>>>> >>>>><br>
>>>> >>>>> But, the default visibility is "default" -- which is the most<br>
>>>> export-y visibility setting there is. So, without specifying visibility<br>
>>>> options on the command line, the only thing you can do with visibility<br>
>>>> attributes in code is to remove exports, not add additional ones.<br>
>>>> >>>>><br>
>>>> >>>>> What am I missing?<br>
>>>> >>>><br>
>>>> >>>> That AIX is not an ELF platform. AIX has a default visibility for<br>
>>>> XCOFF called "unspecified". This is because the ELF-based visibility<br>
>>>> options do not quite match the base case on AIX. That the most export-y<br>
>>>> visibility is named "default" at the source level is an ELF-ism.<br>
>>>> >>><br>
>>>> >>><br>
>>>> >>> But Clang doesn't have an "unspecified" visibility, only default,<br>
>>>> protected, and hidden. And this proposal doesn't propose to add one,<br>
>>>> either. So I don't see how this command-line option makes sense in Clang,<br>
>>>> right now.<br>
>>>> >><br>
>>>> >> It makes sense for Clang on AIX if it improves the consistency of<br>
>>>> behaviour with other compilers on that platform. GCC on AIX does not<br>
>>>> support encoding visibility into XCOFF and the default behaviour of the IBM<br>
>>>> xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF.<br>
>>>> That there will be future complementary changes does not seem to be a<br>
>>>> practical reason for leaving Clang gratuitously different on AIX from other<br>
>>>> AIX compilers.<br>
>>>> ><br>
>>>> ><br>
>>>> > If clang did not implement this feature, symbols marked<br>
>>>> visibility("hidden") or visibility("protected") will actually be marked<br>
>>>> hidden/protected in the output on AIX. If clang does implement this<br>
>>>> feature, such symbols will instead be marked as exported<br>
>>>> default-visibility. There is no change for symbols marked<br>
>>>> visibility("default").<br>
>>>> ><br>
>>>> > So, the request here is that Clang on AIX should ignore the attempt to<br>
>>>> hide symbols, resulting in symbols being exported, even though the code<br>
>>>> thought it was hiding them? That's the desired behavior change?<br>
>>>> ><br>
>>>> > I remain unclear as to how that is a useful or important feature. Are<br>
>>>> you worried about compatibility with code which incorrectly specified<br>
>>>> visibility("hidden"), when it actually did need to export the symbol?<br>
>>>><br>
>>>> The same feeling here... Aren't most<br>
>>>> __attribute__((visibility("hidden"))) guarded by macros? AIX can turn<br>
>>>> off the macros...<br>
>>>> _______________________________________________<br>
>>>> cfe-dev mailing list<br>
>>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>>>><br>
>>> _______________________________________________<br>
>>> cfe-dev mailing list<br>
>>> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
>>> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
>>><br>
>><br>
</blockquote></div>