[llvm-dev] LLVM miscompiles globals with absolute_symbol metadata?

Haoran Xu via llvm-dev llvm-dev at lists.llvm.org
Thu Sep 9 23:52:41 PDT 2021


Hello,

According to LLVM documentation (
https://llvm.org/docs/LangRef.html#absolute-symbol-metadata), the
'absolute_symbol' metadata can be applied to a global to force absolute
relocations and allows expressing the range of the address for the symbol.

However, it seems like LLVM miscompiles the following simple example:

target datalayout =
> "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-unknown-linux-gnu"
>
> @f = external dso_local global i32, align 4, !absolute_symbol !0
>
> define dso_local i64 @g(i64 %0) {
>   %2 = add i64 %0, ptrtoint (i32* @f to i64)
>   ret i64 %2
> }
>
> !0 = !{ i64 0, i64 1000000000000000000 }
>

After compiling using 'llc -O=3 -filetype=obj test.ll', I get the following
output:

>
> 0000000000000000 <g>:
>    0: 48 8d 87 00 00 00 00 lea    0x0(%rdi),%rax
> 3: R_X86_64_32S f
>    7: c3                   retq
>

This is wrong because 'f' has an address range larger than signed 32 bits.

However, if I change the IR to

>   %2 = add i64 %0, mul(i64 ptrtoint (i32* @f to i64), i64 2)
>
LLVM compiles correctly and generates an R_X86_64_64 relocation record.

So it seems like a bug in the x86-64 backend lowering where absolute_symbol
is not respected in some cases? Any idea on what the problem is and how to
fix it?

Thanks,
Haoran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210909/2b46afab/attachment.html>


More information about the llvm-dev mailing list