[llvm-dev] lld write wrong symbol value in .data section if enable -pie

Mon Jan 28 09:55:28 PST 2019

Hello Steven,

One difference between ld.lld and ld.bfd is that ld.lld defaults to
--no-apply-dynamic-relocs (do not write the relocation addend) and ld.bfd
defaults to --apply-dynamic-relocs (write the relocation addend). Can you
try again with --apply-dynamic-relocs ?

Note that for RELA relocations a dynamic loader is supposed to resolve the
relocation using the Addend in the relocation, ignoring the value in the
place (.data section in your case). When linking -pie it is generally
assumed that you will have a dynamic loader to resolve any relocations
resulting from it so I don't think LLD is incorrect to put 0 in the .data
section in this case.

There are a couple of things I don't understand about the output though:
- If the symbol we are relocating against has hidden visibility I'd expect
a R_X86_64_RELATIVE relocation without a symbol for a -pie link.
- I thought R_X86_64_64 wasn't a dynamic relocation? I'm not that familiar
with X86 so I could be missing something glaringly obvious here.

If --apply-dynamic-relocs doesn't work, would you consider making a small
example and perhaps raise a PR? If it turns out not to be a problem we can
always close it.

Peter

On Mon, 28 Jan 2019 at 15:35, Shi, Steven via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Rui,
>
> I still fail to enable the lld in my Uefi firmware build to replace ld,
> and I found it is related to the wrong symbol values in the .data section,
> which are pointed by R_X86_64_64 relocation entries. I need your advices.
>
>
>
> My firmware uses a linker script
> https://github.com/tianocore/edk2/blob/master/BaseTools/Scripts/GccBase.lds
> to do the linking. We use position independent code with hidden visibility
> to inform the compiler that symbol references are never resolved at
> runtime. My problem is I found after the lld linking with –pie enabled, the
> symbol values in .data section, which have the R_X86_64_64 relocation
> entries, are all 0. In other word, I found the S in below R_X86_64_64
>  calculation is 0.
>
>
>
> Name: R_X86_64_64
>
> 1
>
> *word64 *
>
> S + A
>
>
>
> Below is an example to compare the lld and ld, sorry about the verbose.
>
> 1.       Firstly, I use lld to link a HelloWorld module with -pie enabled:
>
> "/home/jshi19/llvm/releaseinstall/bin/ld.lld" -pie -z relro
> --hash-style=gnu --eh-frame-hdr -m elf_x86_64 -dynamic-linker
> /lib64/ld-linux-x86-64.so.2 -o
> /home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> -u _ModuleEntryPoint -L/usr/lib/gcc/x86_64-linux-gnu/7.3.0
> -L/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu
> -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../..
> -L/home/jshi19/llvm/releaseinstall/bin/../lib -L/lib -L/usr/lib -q
> --gc-sections -z max-page-size=0x40 --entry _ModuleEntryPoint -Map
> /home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.map
> --whole-archive -O0 -melf_x86_64 --oformat elf64-x86-64 --start-group
> @/home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/OUTPUT/static_library_files.lst
> --end-group --defsym=PECOFF_HEADER_SIZE=0x228
> --script=/home/jshi19/wksp_efi/lgao4/edk2/BaseTools/Scripts/GccBase.lds
>
>
>
> 2.       Then, I check the R_X86_64_64 relocation entries in .rela.data
> section, and find their target offsets
>
> $ readelf -r
> /home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
>
> Relocation section '.rela.data' at offset 0x5b7e8 contains 41 entries:
>
>   Offset          Info           Type           Sym. Value    Sym. Name +
> Addend
>
> … …
>
> 000000005040  00d600000001 R_X86_64_64       0000000000003130
> TestFunction1 + 0
>
> 000000005048  00d700000001 R_X86_64_64       0000000000003150
> TestFunction2 + 0
>
>
>
> 3.       Next, I check the symbol values in .data section which are
> targeted by above R_X86_64_64 relocatons
>
> $ readelf -x2 HelloWorld.dll
>
>
> Hex dump of section '.data':
>
> NOTE: This section has relocations against it, but these have NOT been
> applied to this dump.
>
> … …
>
>   0x00005030 00000000 00000000 00000000 00000000 ................
>
>   0x00005040 00000000 00000000 00000000 00000000 ................
>
>   0x00005050 4ebe7903 06d77d43 b037edb8 2fb772a4 N.y...}C.7../.r.
>
>   0x00005060 00000000 00000000 00000000 00000000 ................
>
> … …
>
> You can see the offset 0x5040 and 0x5048 symbol value are all 0, which is
> not correct.
>
>
>
> But if I remove the -pie option in the above step 1 lld link command, the
> 0x5040 and 0x5048 symbol values are correct.
>
> $ readelf -x2 HelloWorld.dll
>
>
> Hex dump of section '.data':
>
> NOTE: This section has relocations against it, but these have NOT been
> applied to this dump.
>
> … …
>
>   0x00005030 04420000 00000000 00000000 00000000 .B..............
>
>   0x00005040 30310000 00000000 50310000 00000000 01......P1......
>
>   0x00005050 4ebe7903 06d77d43 b037edb8 2fb772a4 N.y...}C.7../.r.
>
>   0x00005060 00000000 00000000 00000000 00000000 ................
>
> … …
>
>
>
> And if I replace lld with ld but still use exact same link options with
> –pie enabled, the R_X86_64_64 symbol values are correct.
>
> 1.       Link again with ld and same link options:
>
> ld -pie -z relro --hash-style=gnu --eh-frame-hdr -m elf_x86_64
> -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o
> /home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.dll
> -u _ModuleEntryPoint -L/usr/lib/gcc/x86_64-linux-gnu/7.3.0
> -L/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../../x86_64-linux-gnu
> -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu
> -L/usr/lib/gcc/x86_64-linux-gnu/7.3.0/../../..
> -L/home/jshi19/llvm/releaseinstall/bin/../lib -L/lib -L/usr/lib -q
> --gc-sections -z max-page-size=0x40 --entry _ModuleEntryPoint -Map
> /home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/DEBUG/HelloWorld.map
> --whole-archive -O0 -melf_x86_64 --oformat elf64-x86-64 --start-group
> @/home/jshi19/wksp_efi/lgao4/edk2/Build/OvmfX64/NOOPT_CLANG38/X64/MdeModulePkg/Application/HelloWorld/HelloWorld/OUTPUT/static_library_files.lst
> --end-group --defsym=PECOFF_HEADER_SIZE=0x228
> --script=/home/jshi19/wksp_efi/lgao4/edk2/BaseTools/Scripts/GccBase.lds
>
>
>
> 2.       Then, check the .rela.data section R_X86_64_64 relocation
> entries:
>
> … …
>
> 000000004f40  00a400000001 R_X86_64_64       0000000000003130
> TestFunction1 + 0
>
> 000000004f48  009a00000001 R_X86_64_64       0000000000003150
> TestFunction2 + 0
>
> … …
>
> 3.       Check the R_X86_64_64 targeting symbol values in .data section
>
> … …
>
>   0x00004f30 f3410000 00000000 00000000 00000000 .A..............
>
>   0x00004f40 30310000 00000000 50310000 00000000 01......P1......
>
>   0x00004f50 00000000 00000000 00000000 00000000 ................
>
> … …
>
> You can see the offset 0x4f40 and 0x4f48 symbol value are not 0, which is
> correct.
>
>
>
> Appreciate if you could give me some advices on how to let lld output
> correct symbol values when enable pie.
>
>
>
>
>
> Thanks
>
> Steven
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190128/b490b10d/attachment.html>