[PATCH] D35944: [ELF] Disable relocation validation when targeting weak undefined symbols

[Rafael Avila de Espindola via llvm-commits]

ben via Phabricator <reviews at reviews.llvm.org> writes:
> Hi Rafael,
>
> The behaviour for weak references is different across different platforms.
>
> For example on arm and power you can write.
>
> void f1() __attribute__((weak));
> void main() {f1();}
>
> Which can be expected to work correctly. However, this may fault on x86_64.

Yes, but that is not the difference I am referring to.

>> I think that is a bug in llvm on x86_64. I will take a quick look.
>
> That does look like a bug. However, in general the codegen should not account for the possibility that the reference is unresolved - because we want to generate identical code as for strong references for the case that the weak reference is resolved. i.e:
>
> "void f1() __attribute__((weak)); void f2() {f1();}" and "void f1(); void f2() {f1();}"
>
> should codegen identically.

That is fine. It is as call and can refer to a plt entry. Either with a
plt relocation on with the linker creating a special one.

> Another way to see what the right behaviour should be here is to draw a comparison with the lld feature "--unresolved-symbols=ignore-all".
>
> If I link this example:
>
> void f1(); void main() {f1();}
>
> At a high address, e.g. "lld main.o -Ttext=0xbadbadbad" - I get an undefined symbol error.  If I link the same example with: "lld main.o -Ttext=0xbadbadbad --unresolved-symbols=ignore-all" the link should succeed. It would clearly be a bug here to warn about an overflowing relocation - the same logic should apply to weak references.

It is not the same. The difference is that in this case there is a
call. It is also relevant that lld will produce a dynamic relocation if
the program has any shared libraries. It should not do that with an weak
undefined.

Cheers,
Rafael