<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 5, 2018 at 1:50 PM Stephen Checkoway via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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">Hi Peter,<br>
<br>
I hadn't noticed that line about RELA in the ABI document, thanks! I agree that this is a bug in objcopy. I'll file a bug against objcopy.<br>
<br>
It seems that lld already supports relocations that don't comply with the standard (namely R_X86_64_16 and R_X86_64_8 <<a href="https://github.com/hjl-tools/x86-psABI/blob/hjl/master/object-files.tex#L554" rel="noreferrer" target="_blank">https://github.com/hjl-tools/x86-psABI/blob/hjl/master/object-files.tex#L554</a>>), but I guess that's different than supporting an entirely different format.<br></blockquote><div><br></div><div>lld supports the extension because LLVM supports the extension too (<a href="https://llvm.org/docs/Extensions.html#x86">https://llvm.org/docs/Extensions.html#x86</a>). But yeah, as you said, that's a small extension to the standard, and that's different from supporting an entirely different format.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Thanks for looking into this.<br>
<br>
Steve<br>
<br>
> On Jun 5, 2018, at 14:34, Peter Collingbourne via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> <br>
> Hi Stephen,<br>
> <br>
> I think the bug is in objcopy, as it is creating a file that does not comply with the x86-64 psABI, which requires all relocations to be RELA:<br>
> <a href="https://github.com/hjl-tools/x86-psABI/blob/hjl/master/object-files.tex#L429" rel="noreferrer" target="_blank">https://github.com/hjl-tools/x86-psABI/blob/hjl/master/object-files.tex#L429</a><br>
> I also tried passing your bug-64.o to ld.gold, and it rejects it with an internal error.<br>
> <br>
> $ ld.gold -r -o bug-64-2.o bug-64.o<br>
> ld.gold: internal error in scan_relocatable_relocs, at ../../gold/x86_64.cc:5118<br>
> $ ld.gold  -o bug-64-2.o bug-64.o<br>
> ld.gold: error: bug-64.o: unsupported REL reloc section<br>
> ld.gold: internal error in relocate_section, at ../../gold/x86_64.cc:5051<br>
> <br>
> Probably what needs to happen is that we need to start rejecting files which use the wrong relocation type and a bug needs to be filed against objcopy.<br>
> <br>
> Peter<br>
> <br>
> On Tue, Jun 5, 2018 at 10:33 AM, Stephen Checkoway via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hi,<br>
> <br>
> I've tracked down what I believe is a bug in lld's relocation processing for R_X86_64_PC32 REL relocations.<br>
> <br>
> I'm producing the object file in a slightly unusual way: I'm using objcopy on a relocatable i386 ELF object file to convert it to x86_64 which transforms a R_386_PC32 into a R_X86_64_PC32.<br>
> <br>
> Steps to reproduce:<br>
> <br>
> 1. Assemble the attached bug.asm using nasm and note the R_386_PC32 REL.<br>
> <br>
> $ nasm -felf32 -o bug.o bug.asm<br>
> $ x86_64-elf-objdump -dr bug.o | grep -A1 -e '<_start>:'<br>
> 00000000 <_start>:<br>
>    0:   e8 fc ff ff ff          call   1 <_start+0x1><br>
> $ x86_64-elf-readelf -r bug.o<br>
> <br>
> Relocation section '.rel.text._start' at offset 0x260 contains 1 entry:<br>
>  Offset     Info    Type            Sym.Value  Sym. Name<br>
> 00000001  00000302 R_386_PC32        00000000   .text.foo<br>
> <br>
> 2. Convert bug.o to a 64-bit ELF object file and note the R_X86_64_PC32 REL (not RELA!)<br>
> <br>
> $ x86_64-elf-objcopy -I elf32-i386 -O elf64-x86-64 bug.o bug-64.o<br>
> $ x86_64-elf-objdump -M i386 -dr bug-64.o | grep -A1 -e '<_start>:'<br>
> 0000000000000000 <_start>:<br>
>    0:   e8 fc ff ff ff          call   1 <_start+0x1><br>
> $ x86_64-elf-readelf -r bug-64.o<br>
> <br>
> Relocation section '.rel.text._start' at offset 0x128 contains 1 entry:<br>
>   Offset          Info           Type           Sym. Value    Sym. Name<br>
> 000000000001  000300000002 R_X86_64_PC32     0000000000000000 .text.foo<br>
> <br>
> 3. Link with a just-built ld.lld and note that the relocation has been misapplied. It's now calling foo+4 rather than foo.<br>
> <br>
> $ ./llvm-build/bin/ld.lld -melf_x86_64 -o bug-lld bug-64.o<br>
> $ x86_64-elf-objdump -M i386 -d bug-64-lld | grep -A1 -e '<_start>:'<br>
> 0000000000201000 <_start>:<br>
>   201000:       e8 0f 00 00 00          call   201014 <foo+0x4><br>
> <br>
> If you link with GNU ld instead, the relocation is applied correctly.<br>
> <br>
> $ x86_64-elf-ld -melf_x86_64 -o bug-64-ld bug-64.o<br>
> $ x86_64-elf-objdump -M i386 -d bug-64-ld | grep -A1 -e '<_start>:'<br>
> 0000000000400080 <_start>:<br>
>   400080:       e8 0b 00 00 00          call   400090 <foo><br>
> <br>
> Linking the 32-bit object file works correctly with both GNU ld and ld.lld.<br>
> <br>
> $ ./llvm-build/bin/ld.lld -melf_i386 -o bug-lld bug.o<br>
> $ x86_64-elf-objdump -d bug-lld | grep -A1 -e '<_start>:'<br>
> 00011000 <_start>:<br>
>    11000:       e8 0b 00 00 00          call   11010 <foo><br>
> $ x86_64-elf-ld -melf_i386 -o bug-ld bug.o<br>
> $ x86_64-elf-objdump -d bug-ld | grep -A1 -e '<_start>:'<br>
> 08048060 <_start>:<br>
>  8048060:       e8 0b 00 00 00          call   8048070 <foo><br>
> <br>
> I'm not at all familiar with the lld source, but this looks a lot like getImplicitAddend() needs to be implemented for the X86_64 class.<br>
> <br>
> Alternatively (but much less useful for me) would be an error message that REL relocations are not supported on x86-64.<br>
> <br>
> I've attached all of the files created above, in case anyone wants to examine them.<br>
> <br>
> Thank you,<br>
> <br>
> Steve<br>
> <br>
> -- <br>
> Stephen Checkoway<br>
> <br>
> <br>
> <br>
> <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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> -- <br>
> Peter<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
<br>
-- <br>
Stephen Checkoway<br>
<br>
<br>
<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="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>