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

[Kaelyn Takata]

Yeah, I can do that (though I probably won't get to it until Monday).
Thanks for coming up with the patch!


On Sat, Apr 12, 2014 at 4:25 PM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140412/caca630c/attachment.html>