[PATCH] D38554: Fixed ppc32 function relocations in non-pic mode

[Hal Finkel via Phabricator via llvm-commits]

hfinkel added a comment.

In https://reviews.llvm.org/D38554#904915, @vit9696 wrote:

> @hfinkel, that sounded like a good idea in the beginning, but after I implemented it by changing the condition to the following:
>
>   bool Local = TM.shouldAssumeDSOLocal(*Mod, GV);
>   // Do not use the PLT when explicitly told to do so
>   if (!Local && GV && GV->isDeclarationForLinker()) {
>     const Function *F = dyn_cast_or_null<Function>(GV);
>     Local = F && F->hasFnAttribute(Attribute::NonLazyBind);
>   }
>   bool UsePlt = !Local && Subtarget.isTargetELF() && !isPPC64;
>   
>
> It did not quite work out. Consider the following example:
>
>   unsigned long long fn1();
>   unsigned fn2();
>  
>   int __start() {
>     unsigned long long v1 = fn1();
>     unsigned v2 = fn2();
>     return v1 % v2;
>   }
>
>
> With -fno-plt and this patch added fn1 and fn2 would work just fine, however, v1 % v2 resolving to __umoddi3 would not, since GV would be null in the first place.


Interesting. Thanks for trying this.

> I am not sure if this can be handled without breaking shared builtins linkage, to be honest. So adding basic PLTREL support for lld might be easier after all since IFUNCs are already supported in LLVM and we cannot special case just the relocation model. I submitted a patch here: https://reviews.llvm.org/D39226. I can also submit the -fno-plt patch as well (for completeness) but I am afraid it will be of no real use due to builtins.

Improving lld is clearly a good thing. If there's interest, we can also look at actually adding support for the embedded ABI (and this can be done incrementally). If improving lld meets our needs and we don't need to add specific EABI handling for now, that's fine too.


https://reviews.llvm.org/D38554