Re: llvm self-tests looping(?)

[Havard Eidnes <he%NetBSD.org@localhost>]

And ... as follow-up I thought I'd check whether "make test" in
lang/llvm (5.0.1nb1) works on NetBSD/amd64 8.0_BETA.  And while the
selftest setup seems to work fine on this platform, there are quite a
bit of unexpected failures:

  Expected Passes    : 20309
  Expected Failures  : 130
  Unsupported Tests  : 786
  Unexpected Failures: 211

and it seems a lot of the tests simply crash.  An example:

********************
Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60
FAIL: LLVM :: ExecutionEngine/test-interp-vec-logical.ll (13657 of 21436)
******************** TEST 'LLVM :: ExecutionEngine/test-interp-vec-logical.ll' FAILED ********************
Script:
--
/usr/pkgsrc/lang/llvm/work/build/./bin/lli /usr/pkgsrc/lang/llvm/work/llvm-5.0.0.src/test/ExecutionEngine/test-interp-vec-logical.ll > /dev/null
--
Exit Code: 139

Command Output (stderr):
--
#0 0x00007138327c701a llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/usr/pkgsrc/lang/llvm/work/build/lib/libLLVM-5.0.so+0x7c701a)
#1 0x00007138327c536f llvm::sys::RunSignalHandlers() (/usr/pkgsrc/lang/llvm/work/build/lib/libLLVM-5.0.so+0x7c536f)
#2 0x00007138327c54b0 SignalHandler(int) (/usr/pkgsrc/lang/llvm/work/build/lib/libLLVM-5.0.so+0x7c54b0)
Stack dump:
0.      Program arguments: /usr/pkgsrc/lang/llvm/work/build/./bin/lli /usr/pkgsrc/lang/llvm/work/llvm-5.0.0.src/test/ExecutionEngine/test-interp-vec-logical.ll /usr/pkgsrc/lang/llvm/work/build/test/ExecutionEngine/Output/test-interp-vec-logical.ll.script: line 1: 18054 Segmentation fault      (core dumped) /usr/pkgsrc/lang/llvm/work/build/./bin/lli /usr/pkgsrc/lang/llvm/work/llvm-5.0.0.src/test/ExecutionEngine/test-interp-vec-logical.ll > /dev/null

However, this doesn't appear to actually give enough information to
zero in on what the actual problem is, sigh!

Isn't the backtracer able to trace through signal delivery events?

I find there's a number of core files left after the selftests have
run:

d3: {10} find work -name '*.core'
work/build/test/MCJITTests.core
work/build/test/OrcJITTests.core
work/build/test/SupportTests.core
work/build/test/BugPoint/opt.core
work/build/test/ExecutionEngine/MCJIT/lli.core
work/build/test/ExecutionEngine/OrcMCJIT/lli.core
work/build/test/ExecutionEngine/lli.core
d3: {11}

but looking at the last one doesn't really give much more useful
information:

d3: {11} gdb -q work/build/./bin/lli
Reading symbols from work/build/./bin/lli...(no debugging symbols found)...done.
(gdb) core-file work/build/test/ExecutionEngine/lli.core
[New process 1]
Core was generated by `lli'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000701d30805000 in main ()
(gdb) x/i 0x0000701d30805000
=> 0x701d30805000 <main>:       xor    %eax,%eax
(gdb) where
#0  0x0000701d30805000 in main ()
#1  0x0000701d2e95bf17 in llvm::MCJIT::runFunction(llvm::Function*, llvm::ArrayRef<llvm::GenericValue>) ()
   from /usr/pkgsrc/lang/llvm/work/build/lib/libLLVM-5.0.so
#2  0x0000701d2e9378ed in llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*, std::vector<std::string, std::allocator<std::string> > const&, char const* const*) () from /usr/pkgsrc/lang/llvm/work/build/lib/libLLVM-5.0.so
#3  0x000000000041cad6 in main ()
(gdb) i reg
rax            0x701d2e95be9a   123270637928090
rbx            0x7f7fffecd600   140187731285504
rcx            0x701d3080b800   123270670104576
rdx            0xffffffffff4350da       -12365606
rsi            0x20     32
rdi            0x701d2d1236e0   123270612530912
rbp            0x20     0x20
rsp            0x7f7fffecd458   0x7f7fffecd458
r8             0x0      0
r9             0x701d2d1151c0   123270612472256
r10            0x701d30805000   123270670077952
r11            0x207    519
r12            0x701d30805000   123270670077952
r13            0x701d2d16c000   123270612828160
r14            0x701d2d1236e0   123270612530912
r15            0x701d2c558b00   123270600166144
rip            0x701d30805000   0x701d30805000 <main>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x47     71
ss             0x3f     63
ds             0x3f     63
es             0x3f     63
fs             0x0      0
gs             0x0      0
(gdb) 

?!?  SEGV on "xor %eax,%eax"?!?  I don't think so...

Regards,

- Håvard