<div dir="ltr">> I remain unclear as to how that is a useful or important feature. Are you worried about compatibility with code which incorrectly specified visibility("hidden"), when it actually did need to export the symbol?<div><br></div><div>I guess I understand the point of confusion, so I will try to clarify it a little bit. </div><div>It goes back to Clang does not have "unspecified" visibility mapping yet. On AIX, the baseline visibility is not "default" or export. The baseline visibility is "unspecified" when no attribute is marked on the symbol. </div><div>And -mignore-xcoff-visibility means let all the symbols have "unspecified" visibility, whether or not any visibility attribute is specified on the symbol. So that user could use export list in the link step to control the visibility on AIX, which gives a more fine-grained control. </div><div>As it is right now, the llc on AIX actually treats `GlobalValue::DefaultVisibility` as "unspecified" as it is the baseline visibility mode on AIX. So it is a bit messy there, and we will need to clean that up when we add "unspecified" visibility attribute to clang for AIX. But I don't think it should prevent us from making the default behavior(unspecified visibility for all symbols) right on AIX for now. </div><div>Hope that would clean up the confusion.</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 15, 2020 at 2:35 PM Fāng-ruì Sòng via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</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 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 <<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>> wrote:<br>
>>><br>
>>> On Thu, Sep 10, 2020 at 10:30 PM Hubert Tong <<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>> wrote:<br>
>>>>><br>
>>>>><br>
>>>>><br>
>>>>> On Thu, Sep 10, 2020, 6:57 PM Hubert Tong <<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 <<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 via attribute? Especially by default?<br>
>>>>>><br>
>>>>>> One reason is that AIX performs more early/less lazy symbol resolution (even with runtime linking) than, say, Linux. So, if a project goes with an export-by-default model (via attribute in some scope), they can cause link-time errors from symbol references to undefined symbols from code that would otherwise have been discarded as unreferenced by the linker. It seems such code is not uncommon (and has the questionable effect of exporting template instantiations based on "client provided" types that are not part of the "library"/"utility" code in question).<br>
>>>>><br>
>>>>><br>
>>>>> But, the default visibility is "default" -- which is the most export-y visibility setting there is. So, without specifying visibility options on the command line, the only thing you can do with visibility 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 XCOFF called "unspecified". This is because the ELF-based visibility options do not quite match the base case on AIX. That the most export-y 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, protected, and hidden. And this proposal doesn't propose to add one, either. So I don't see how this command-line option makes sense in Clang, right now.<br>
>><br>
>> It makes sense for Clang on AIX if it improves the consistency of behaviour with other compilers on that platform. GCC on AIX does not support encoding visibility into XCOFF and the default behaviour of the IBM xlclang/xlclang++ compiler on AIX is to not encode visibility into XCOFF. That there will be future complementary changes does not seem to be a practical reason for leaving Clang gratuitously different on AIX from other AIX compilers.<br>
><br>
><br>
> If clang did not implement this feature, symbols marked visibility("hidden") or visibility("protected") will actually be marked hidden/protected in the output on AIX. If clang does implement this feature, such symbols will instead be marked as exported default-visibility. There is no change for symbols marked visibility("default").<br>
><br>
> So, the request here is that Clang on AIX should ignore the attempt to hide symbols, resulting in symbols being exported, even though the code 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 you worried about compatibility with code which incorrectly specified 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>
</blockquote></div>