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

[Rafael Espíndola]

getAccessVariant is fairly incomplete. The attached patch should fix this case.

"Unfortunately" I will be on vacations next week and mostly out of the
internet during that time. Can you commit the patch if it does fix the
issue for you? I will try to write a more complete version when I get
back (on the 20th).

On 12 April 2014 00:50, Kaelyn Takata <rikka at google.com> wrote:
> 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 --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: application/octet-stream
Size: 1214 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140413/4b28bfc9/attachment.obj>