[llvm] r204294 - Look through variables when computing relocations.

Kaelyn Takata rikka at google.com
Fri Apr 11 16:50:09 PDT 2014


On Thu, Mar 20, 2014 at 9:35 AM, Alexander Kornienko <alexfh at google.com>wrote:

> On Thu, Mar 20, 2014 at 5:23 PM, Rafael EspĂ­ndola <
> rafael.espindola at gmail.com> wrote:
>
>> On 20 March 2014 04:58, Alexander Kornienko <alexfh at google.com> wrote:
>> > Either this revision or r204293 breaks something again (in a different
>> > place, though). I'll post details once I have more information.
>>
>> Open source place? I do have a build with compiler-rt in a linux vm
>
> that I can use to reproduce the problem.
>>
>
> Actually, I don't have a reliable repro. It shows as a linking error:
>
> <some file>.o: requires unsupported dynamic reloc 14; recompile with -fPIC
>
>
I have narrowed down the source of the problem within r204293, affecting
the integrated assembler:

--- llvm/trunk/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp (original)
+++ llvm/trunk/lib/Target/X86/MCTargetDesc/X86ELFObjectWriter.cpp Wed Mar
19 21:12:01 2014
@@ -46,8 +46,7 @@ unsigned X86ELFObjectWriter::GetRelocTyp
                                           int64_t Addend) const {
   // determine the type of the relocation

-  MCSymbolRefExpr::VariantKind Modifier = Target.isAbsolute() ?
-    MCSymbolRefExpr::VK_None : Target.getSymA()->getKind();
+  MCSymbolRefExpr::VariantKind Modifier = Fixup.getAccessVariant();
   unsigned Type;
   if (getEMachine() == ELF::EM_X86_64) {
     if (IsPCRel) {

In the failing case, Fixup.getAccessVariant() is hitting the
llvm_unreachable... but the bad reloc happens due to the undefined behavior
of llvm_unreachable in an optimized build with assertions disabled. The
offending code was the gfortran-generated assembly of zgbtrf.f from lapack
(both 3.3.1 and 3.5.0 were hitting the problem, at least with -fPIC
enabled) being passed to clang.

I've narrowed down the assembly to a one-line test case. (FYI,
"work13.1909" was the name of a local variable in the original generated
assembly, but not having it defined at all doesn't affect the results;
either way there should be one relocation of type R_X86_64_PC32.)

$ cat zgbtrf.S
        leaq    -1040+work13.1909(%rip), %r11

$ build/bin/clang -cc1as -o x.o zgbtrf.S -triple x86_64-unknown-linux-gnu
-filetype obj -target-cpu x86-64
unsupported
UNREACHABLE executed at llvm/lib/MC/MCFixup.cpp:17!
0  clang           0x0000000001811a4e llvm::sys::PrintStackTrace(_IO_FILE*)
+ 46
1  clang           0x0000000001811d0b
2  clang           0x0000000001811f7e
3  libpthread.so.0 0x00007f28707bfcb0
4  libc.so.6       0x00007f286f9fa425 gsignal + 53
5  libc.so.6       0x00007f286f9fdb8b abort + 379
6  clang           0x00000000017d1246
7  clang           0x0000000003aaa523
8  clang           0x0000000003aaa5ab
9  clang           0x0000000003aaa5ab
10 clang           0x0000000003aaa4bd llvm::MCFixup::getAccessVariant()
const + 29
11 clang           0x0000000001bda04f
12 clang           0x0000000003a9c2e2
13 clang           0x0000000003a94255
14 clang           0x0000000001601778
llvm::MCAssembler::handleFixup(llvm::MCAsmLayout const&, llvm::MCFragment&,
llvm::MCFixup const&) + 392
15 clang           0x0000000001601cbc llvm::MCAssembler::Finish() + 1308
16 clang           0x0000000003ab0c2d llvm::MCObjectStreamer::FinishImpl()
+ 93
17 clang           0x0000000003aa867a llvm::MCELFStreamer::FinishImpl() + 74
18 clang           0x0000000001633526 llvm::MCStreamer::Finish() + 150
19 clang           0x000000000163e32e
20 clang           0x0000000000912dc5
21 clang           0x0000000000910b19 cc1as_main(char const**, char
const**, char const*, void*) + 1033
22 clang           0x0000000000905104 main + 996
23 libc.so.6       0x00007f286f9e576d __libc_start_main + 237
24 clang           0x0000000000904bc5
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140411/f875a48b/attachment.html>


More information about the llvm-commits mailing list