On Thu, 5 Sep 2024, Evgeny Karpov wrote:
Monday, September 2, 2024
Martin Storsjö <mar...@martin.st>
The patch adds support for weak references. The original MinGW
implementation targets ix86, which handles weak symbols differently
compared to AArch64.
Please clarify this statement.
Here is an explanation of why this change is needed and what the
difference is between x86_64-w64-mingw32 and aarch64-w64-mingw32.
The way x86_64 calls a weak function:
call weak_fn2
GCC emits the call and creates the required definitions at the end
of the assembly:
.weak weak_fn2
.def weak_fn2; .scl 2; .type 32; .endef
This is different from aarch64:
weak_fn2 will be legitimized and replaced by .refptr.weak_fn2,
and there will be no other references to weak_fn2 in the code.
adrp x0, .refptr.weak_fn2
add x0, x0, :lo12:.refptr.weak_fn2
ldr x0, [x0]
blr x0
Right, this is the core of what I'm arguing here.
Is there any intrinsic reason why there _should_ be a difference to x86_64
here? Because most of the same reasons for why aarch64 wants to do
indirection via .refptr here also do apply for x86_64.
Or to put it in more clear words: I think x86_64 also should use .refptr
for weak symbols.
There are a number of open bugs for GCC targeting x86_64 mingw, regarding
weak symbols, and I think a few of them could be solved if GCC would use
.refptr for the weak symbols on x86_64 as well.
So I don't argue that this change is wrong, it probably is correct.
But I'm arguing that there shouldn't be any difference between the
architectures regarding how it is handled. Whenever there's an
architecture difference in such a matter which shouldn't be architecture
specific, there may be a latent bug hiding.
That's not necessarily a blocker for this patch though, but the wording
should make it clear: There's no specific reason for why aarch64 should
behave differently than x86_64, but the x86_64 implementation probably
needs to catch up.
// Martin
