<div dir="ltr"><div dir="ltr"><div><div>Missed adding the dev-list in the reply so resending.<br><br>I believe the bug is that Clang should be setting the e_flags
field in the ELF header to 1 when producing an object file which uses
the function-descriptor based ABI. LLD only supports the V2 ELF ABI for
PowerPC64, which doesn't use function descriptors. LLD will accept
object files with e_flags equal to 2 (V2 ABI specific) or 0 (unspecified
nature),and without the correct flags LLD unfortunately can't detect
the invalid input. <br></div><div><br></div><div>Regards</div><div>Sean<br></div></div><div><br></div><font color="#888888"><div><br></div></font></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 10:04 AM Sean Fertile <<a href="mailto:sd.fertile@gmail.com">sd.fertile@gmail.com</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"><div dir="ltr"><div><div>I believe the bug is that Clang should be setting the e_flags field in the ELF header to 1 when producing an object file which uses the function-descriptor based ABI. LLD only supports the V2 ELF ABI for PowerPC64, which doesn't use function descriptors. LLD will accept object files with e_flags equal to 2 (V2 ABI specific) or 0 (unspecified nature),and without the correct flags LLD unfortunately can't detect the invalid input. </div><br></div>Regards<br><div>Sean</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Apr 2, 2020 at 1:34 AM Amol via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-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">Hello,<br>
<br>
[clang/lld version 11.0.0, built on 1Apr20 using source<br>
downloaded from github.]<br>
<br>
When compiling for ppc64 big-endian target, a branch-with-link<br>
targets the function descriptor instead of the function entry.<br>
<br>
Below is a sample:<br>
<br>
/*1.c*/<br>
int main();<br>
int _start(){return main();}<br>
<br>
/*2.c*/<br>
int g_var=20;<br>
int main(){return g_var;}<br>
<br>
/* build */<br>
clang -target ppc64 -O3 -c 1.c<br>
clang -target ppc64 -O3 -c 2.c<br>
ld.lld 1.o 2.o<br>
<br>
The dissassembly shows that _start branches to the<br>
FD(0x...230) instead of to the entry point (0x...1f8):<br>
<br>
00000000100101c8 <.text>:<br>
. . .<br>
100101d4: 48 02 00 5d bl 0x10030230; <-- bl to FD?<br>
. . .<br>
100101f8: 3c 62 00 01 addis 3, 2, 1 <-- main entry pt.<br>
100101fc: e8 63 80 3a lwa 3, -32712(3)<br>
10010200: 4e 80 00 20 blr<br>
<br>
SYMBOL TABLE:<br>
0000000010030230 g F .opd 0000000000000018 main<br>
<br>
FD of main:<br>
00000230: 00 00 00 00 10 01 01 f8 00 00 00 00 10 02 82 10<br>
00000240: 00 00 00 00 00 00 00 00<br>
<br>
The compiler emits a relocation within the object 1.o:<br>
RELOCATION RECORDS FOR [.text]:<br>
OFFSET TYPE VALUE<br>
000000000000000c R_PPC64_REL24 main<br>
<br>
The relevant code seems to be the function<br>
PPC64::relocate inside lld/ELF/Arch/PPC64.cpp<br>
when it receives R_PPC64_REL24 as rel (with<br>
val 0x2005c in this particular case).<br>
<br>
GNU ld for ppc64 emits a correct bl instruction.<br>
<br>
Is this a bug with lld, or did I simply miss giving<br>
it a switch on its commandline?<br>
<br>
Thank you,<br>
amol<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div></div>