[PATCH] D113167: [lld-macho] Allow exporting weak def private-extern symbols.
Vy Nguyen via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Fri Nov 5 14:14:21 PDT 2021
oontvoo added a comment.
In D113167#3112543 <https://reviews.llvm.org/D113167#3112543>, @thakis wrote:
> In D113167#3109836 <https://reviews.llvm.org/D113167#3109836>, @oontvoo wrote:
>
>> In D113167#3109188 <https://reviews.llvm.org/D113167#3109188>, @thakis wrote:
>>
>>> That honestly sounds like a bug in your build config, independently of if ld64 allows it, no?
>>
>> I still think that LLD shouldn't conflate the following two cases:
>>
>> // hidden.cc
>> extern __attribute__((weak)) __attribute__((visibility("hidden"))) void foo() {return 5;}
>> int bar() { return foo(); }
>>
>> VS
>>
>> // can_be_hidden.cc (Must be C++, not C)
>> __attribute__((noinline)) inline int foo() { return 5; }
>> int bar() { return foo(); }
>>
>> For the `hidden.cc`, clearly we shouldn't export `foo`. (current behaviour).
>> But for the latter, it should be fine
>
> You can make a case for this, but as far as I understand the only programs where this can make a difference in practice is one with ODR violations, right?
If the copy is private, then I don't think it's strictly ODR violations.
But maybe two orthogonal points here:
- is it correct to make autohide symbols synonym with private-extern? (agreed that it likely has no observable difference in the output)
- is it correct to prevent autohide symbols from being exported? (From the example, there's no reason `foo` shouldn't be exportable - it's a bit weird, yes, but it's not wrong)
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D113167/new/
https://reviews.llvm.org/D113167
More information about the llvm-commits
mailing list