[lld] r263070 - [lto] Add saving the LTO .o file to -save-temps.

Sean Silva via llvm-commits llvm-commits at lists.llvm.org
Sat Jun 4 17:18:44 PDT 2016


On Sat, Jun 4, 2016 at 4:52 PM, Rafael EspĂ­ndola <rafael.espindola at gmail.com
> wrote:

> I think this test needs to create a temporary directory and cd into it:
>
> llvm-nm a.out | FileCheck %s
>
> this could be using a a.out from some other test if the scheduling is
> just right.
>

Good catch. I was staring at my original test case in this patch which had
explicit `-o`..

It looks like this issue was likely introduced in
http://llvm.org/klaus/lld/commit/e60c3351266e56d91bfd60f34d36edbbb3a1c5e1/

-- Sean Silva


>
> Thanks!
>
> Cheers,
> Rafael
>
>
> On 4 June 2016 at 16:30, Sean Silva via llvm-commits
> <llvm-commits at lists.llvm.org> wrote:
> >
> >
> > On Sat, Jun 4, 2016 at 1:43 PM, Chandler Carruth <chandlerc at google.com>
> > wrote:
> >>
> >> Sorry to dredge up an old commit, but I just saw this test spuriously
> >> fail:
> >>
> >>
> >>
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/14073
> >>
> >> My commit seems unlikely to have triggered this, and the next build
> >> "fixed" the test. I'm worried there is something non-deterministic
> going on
> >> here.
> >
> >
> > Thanks for bringing attention to this. This is actually somewhat more
> > troubling.
> >
> > This test case links together save-temps.ll (containing just the function
> > `foo`) with Inputs/save-temps.ll (containing just the function `bar`).
> Yet
> > the error message below shows a reference to a function `f`. I'm baffled
> > about how a function `f` could end up in the nm output here.
> >
> > Maybe `f` is the string `foo` being cut off, but that doesn't make sense
> > since FileCheck's output indicates that it was `bar` that wasn't seen,
> and
> > `bar` would have come first (unless this is a coincidence of the cut off
> > with an ordering nondeterminism).
> >
> > Expanding the possibilities to "the bot may be unreliable / cosmic ray"
> > territory, this could be that Inputs/linkonce.ll or another file
> containing
> > a function `f` is somehow getting used instead of Inputs/save-temps.ll
> > (which, assuming LLD is deterministic, makes sense since `bar` is missing
> > and `f` was found in its place).
> >
> > FAIL: lld :: ELF/lto/save-temps.ll (26092 of 27438)
> > ******************** TEST 'lld :: ELF/lto/save-temps.ll' FAILED
> > ********************
> > Script:
> > --
> > rm -f a.out a.out.lto.bc a.out.lto.o
> > llvm-as
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
> > -o
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp.o
> > llvm-as
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/Inputs/save-temps.ll
> > -o
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp2.o
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/ld.lld
> > -shared -m elf_x86_64
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp.o
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/lld/test/ELF/lto/Output/save-temps.ll.tmp2.o
> > -save-temps
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/llvm-nm
> > a.out |
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/llvm-nm
> > a.out.lto.bc |
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/llvm-nm
> > a.out.lto.o |
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/./bin/FileCheck
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll
> > llvm-dis a.out.lto.bc
> > --
> > Exit Code: 1
> >
> > Command Output (stderr):
> > --
> >
> /home/buildbot/Buildbot/Slave/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/lld/test/ELF/lto/save-temps.ll:18:10:
> > error: expected string not found in input
> > ; CHECK: T bar
> >          ^
> > <stdin>:1:1: note: scanning from here
> > 0000000000002000 d _DYNAMIC
> > ^
> > <stdin>:2:18: note: possible intended match here
> > 0000000000001000 T f
> >                  ^
> >
> > --
> >
> > ********************
> >
> >
> >
> >
> >>
> >> When reading this patch I noticed one thing below:
> >>
> >> On Wed, Mar 9, 2016 at 2:34 PM Sean Silva via llvm-commits
> >> <llvm-commits at lists.llvm.org> wrote:
> >>>
> >>>
> >>>
> ==============================================================================
> >>> --- lld/trunk/test/ELF/lto/save-temps.ll (original)
> >>> +++ lld/trunk/test/ELF/lto/save-temps.ll Wed Mar  9 16:30:05 2016
> >>> @@ -1,10 +1,11 @@
> >>>  ; REQUIRES: x86
> >>> -; RUN: rm -f %t.so %t.so.lto.bc
> >>> +; RUN: rm -f %t.so %t.so.lto.bc %t.so.lto.o
> >>>  ; RUN: llvm-as %s -o %t.o
> >>>  ; RUN: llvm-as %p/Inputs/save-temps.ll -o %t2.o
> >>>  ; RUN: ld.lld -shared -m elf_x86_64 %t.o %t2.o -o %t.so -save-temps
> >>>  ; RUN: llvm-nm %t.so | FileCheck %s
> >>>  ; RUN: llvm-nm %t.so.lto.bc | FileCheck %s
> >>> +; RUN: llvm-nm %t.so.lto.o | FileCheck %s
> >>>
> >>>  target triple = "x86_64-unknown-linux-gnu"
> >>>  target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
> >>> @@ -13,5 +14,5 @@ define void @foo() {
> >>>    ret void
> >>>  }
> >>>
> >>> -; CHECK-DAG: T bar
> >>> -; CHECK-DAG: T foo
> >>> +; CHECK: T bar
> >>> +; CHECK: T foo
> >>
> >>
> >> This change seems odd and unrelated to me.
> >>
> >> If the CHECK-DAG was required, that shows some lack of deterministic
> >> output here. This change seems unlikely to have fixed any such
> >> non-determinism.
> >
> >
> > The CHECK-DAG was because the intent of the test actually doesn't imply
> an
> > order. For example, down the road, LTO is likely to do function layout
> and
> > so these may end up in a different order, and IMO the test shouldn't be
> > fragile.  Rui objected because it "doesn't currently" matter, and I
> > assented.
> >
> > -- Sean Silva
> >
> >>
> >>
> >> Sadly, this seems unlikely to explain the spurious failure I just saw.
> =/
> >
> >
> >
> > _______________________________________________
> > llvm-commits mailing list
> > llvm-commits at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160604/a58acc07/attachment.html>


More information about the llvm-commits mailing list