[LLVMdev] Debugging atom builds?

David Tweed david.tweed at arm.com
Wed Apr 3 06:47:02 PDT 2013


As someone working on ARM, we're interested in this sort of issue, to which
there's not yet a complete solution. Some advice below:

2013/4/3  <llvm.buildmaster at lab.llvm.org>:
> The Buildbot has detected a new failure on builder
clang-atom-d2700-ubuntu-rel while building llvm.
> Full details are available at:
>  http://lab.llvm.org:8011/builders/clang-atom-d2700-ubuntu-rel/builds/7852
> Buildbot URL: http://lab.llvm.org:8011/
> Buildslave for this Build: atom1-buildbot
> Build Reason: scheduler
> Build Source Stamp: [branch trunk] 178634
> Blamelist: timurrrr
> BUILD FAILED: failed check-all

| Can you suggest me a way to debug this without an access to Atom D2700?

The first thing to do is not assume it's necessarily machine specific, so go
to the build that's failed and look at the "configure" stdio output and see
what the arguments are. It might be that if you use those arguments (when
they aren't completely unsupported on your architecture) to configure and
see if you get the same failure. I see that the args include
"--enable-optimized --enable-assertions": is that what you were testing? If
that still doesn't work you can look at the stdio file for the actual tests
and search for "FAILED" to at least see what happened in detail (looks like
a different instruction was emitted).

I ran "make check-all" on my Ubuntu box before committing and yet the
Ubuntu Atom bot went red.
| Is there any way we could write test in a cross-platform way? (i.e. if
| a test passes in one setup, it will pass with any other setup)

As above, it's not necessarily just a "platform" thing; configure options
can also affect processing enough to cause issues. These you can at least
try on your system. But in terms of cross-platform tests, it doesn't seem
possible because while half the time the breakage is "trivial differences
that only crop up when you try to write a test", half the time the
differences reflect a platform difference that would also affect real code.
This clearly isn't ideal, but I guess we'd rather hear about platforms where
stuff doesn't work earlier rather than later.


More information about the llvm-dev mailing list