[LLVMdev] Remaining Compiler-RT failures in ARM

Renato Golin renato.golin at linaro.org
Thu Oct 9 09:29:53 PDT 2014


As of this run:


There are three classes of failures that need fixing before we get the
bot green:

1. AddressSanitizer.BuiltinLongJmpTest Unit Test

Two configurations fail:
 * Asan-arm-inline-Test
 * Asan-arm-with-calls-Test

I wonder what's the best way to run it individually and reduce the
error. I'm not very proficient with the unit tests, and I'd be happy
with some documentation on how to reduce them.

2. Illegal instruction

* AddressSanitizer-arm-linux :: TestCases/mmap_limit_mb.cc
* UndefinedBehaviorSanitizer-Standalone :: TestCases/Misc/bounds.cpp

That board doesn't have NEON. It's uncommon for an ARMv7 SoC to not
have it, but some don't (for example, NVidia Tegra3), so we can't
assume they all have.

The CMake option clearly had "-mfpu=vfpv3" on both C and C++ flags and
the tests should honour that. This is a wider problem, and the
test-suite buildbots also don't honour it and fail on non-NEON ARMv7

I'm not an expert in CMake and even less so in Compiler-RT's setup for
the tests, so pointers on how to fix this would be very welcome.

3. UndefinedBehaviorSanitizer-Standalone :: TestCases/Misc/missing_return.cpp

This test fails on Standalone and pass on AddressSanitizer mode,
making it impossible to mark it as XFAIL. Before making XFAIL more
powerful, I'd rather find the problem and try to solve it.

The file checks for two copies of missing_return.cpp, one for f() and
one for main(), but on ARM's stack trace, there's only one:

$ UBSAN_OPTIONS=print_stacktrace=1 ./missing_return.cpp.tmp
runtime error: execution reached the end of a value-returning function
without returning a value

    #0 0x1c7cf in f()
    #1 0x195cf in __ubsan::ScopedReport::~ScopedReport()
    #2 0x1ae79 in handleMissingReturnImpl(__ubsan::UnreachableData*,
__ubsan::ReportOptions) [clone .constprop.7]
    #3 0x1b31f in __ubsan_handle_missing_return

Maybe the stack is not deep enough? Is it really necessary to get for
main in the stack trace?


More information about the llvm-dev mailing list