Tests failures with llvm 15 and 16
jirislaby opened this issue · comments
I see (both with llvm 15 and 16 but not with llvm 14 -- even when the patches from #1664 are applied):
[ 35s] Failing Tests (3):
[ 35s] KLEE :: Feature/VarArgByVal.c
[ 35s] KLEE :: Runtime/POSIX/DirConsistency.c
[ 35s] KLEE :: Runtime/POSIX/SymFileConsistency.c
Originally posted by @jirislaby in #1664 (comment)
Full build log:
build.log
It's x86_64 build on openSUSE Tumbleweed (using uclibc if that's relevant).
@jirislaby Do you see the same behaviour with the main branch of KLEE as in the current state?
What is strange - at least according to your log files:
[ 25s] KLEE: WARNING ONCE: calling external: syscall(16, 0, 21505, 139108239835136) at runtime/POSIX/fd.c:997 10
[ 25s] KLEE: WARNING ONCE: Alignment of memory from call "malloc" is not modelled. Using alignment of 8.
[ 25s] KLEE: WARNING ONCE: calling __klee_posix_wrapped_main with extra arguments.
[ 25s] KLEE: ERROR: (location information missing) illegal instruction
[ 25s] KLEE: NOTE: now ignoring this error at this location
[ 25s] KLEE: ERROR: EXITING ON ERROR:
[ 25s] Error: illegal instruction
[ 25s] Stack:
[ 25s] #000012088 in vfprintf(139122735349760, 140302335115264, 139103944867840)
[ 25s] #100011477 in vsnprintf(139129714671616, 1024, 140302335115264, 139103944867840)
[ 25s] #200010851 in snprintf(139129714671616, 1024, 140302335115264)
[ 25s] #300007730 in __klee_posix_wrapped_main(1, 139441099800576) at test/Runtime/POSIX/SymFileConsistency.c:29
[ 25s] #400006833 in __user_main(4, 140317809999872, 140317809999912) at runtime/POSIX/klee_init_env.c:245
[ 25s] #500000411 in __uClibc_main(140303037661184, 4, 140317809999872, 0, 0, 0, 0)
[ 25s] #600000478 in main(4, 140317809999872)
The generated code contains an illegal instruction. This only happens if an instruction currently unhandled by KLEE is executed.
Which LLVM version are you using?
Yes, it's with 9336cd2. And llvm 16.0.6 (see the build log).
Could you attach the bitcode file with the illegal instruction?
Could you attach the bitcode file with the illegal instruction?
+1 The three .bc files attached + the uclibc libc.a (as a bcs.tar.gz due to github no support for .bc upload). It seems the illegal instruction is in its vfprintf?
Note uclibc is built with --enable-release. Now I added -g to the build of uclibc, so (the build log in #1691 (comment) will be updated shortly):
[ 26s] KLEE: ERROR: libc/stdio/_vfprintf.c:1613: illegal instruction
[ 26s] KLEE: NOTE: now ignoring this error at this location
[ 26s] KLEE: ERROR: EXITING ON ERROR:
[ 26s] Error: illegal instruction
[ 26s] File: libc/stdio/_vfprintf.c
[ 26s] Line: 1613
[ 26s] assembly.ll line: 12723
[ 26s] State: 1
[ 26s] Stack:
[ 26s] #000012723 in vfprintf(139166493294592, 140354823503872, 139156292747264) at libc/stdio/_vfprintf.c:1613
[ 26s] #100012161 in vsnprintf(139160587714560, 64, 140354823503872, 139156292747264) at libc/stdio/vsnprintf.c:64
[ 26s] #200011406 in snprintf(139160587714560, 64, 140354823503872) at libc/stdio/snprintf.c:25
[ 26s] #300007953 in __klee_posix_wrapped_main(1, 139492373938176) at test/Runtime/POSIX/DirConsistency.c:67
[ 26s] #400006864 in __user_main(4, 140369084137472, 140369084137512) at runtime/POSIX/klee_init_env.c:245
[ 26s] #500000435 in __uClibc_main(140353808482304, 4, 140369084137472, 0, 0, 0, 0) at libc/misc/internals/__uClibc_main.c:401
[ 26s] #600000512 in main(4, 140369084137472)
From assembly.ll:
%175 = load i32, ptr %29, align 8, !dbg !11049, !noalias !10961
%176 = icmp slt i32 %175, 0, !dbg !11050
%177 = select i1 %176, i32 1, i32 %175, !dbg !11051
%178 = freeze i32 %177, !dbg !11052 <--- HERE
call void @llvm.dbg.value(metadata i32 %177, metadata !1364, metadata !DIExpression()), !dbg !10957
%179 = and i32 %170, 16, !dbg !11030
%180 = icmp eq i32 %179, 0, !dbg !11030
br i1 %180, label %190, label %181, !dbg !11057The freeze instruction is mainly generated if optimised code is generated.
Right, if I remove --enable-release from uclibc, only the VarArgByVal failure remains.
@jirislaby Can you check if #1692 solves your problem?
Yes, the VarArgByVal failure is gone by that. So now, should freeze be supported? Note it's impossible to build some code wihout optimizations (like kernel).
@jirislaby Thanks for the feedback. Agreed in the long run, we need to add support for freeze.
Indeed, and contributions would be useful. In the upcoming KLEE 3.1, we will continue to recommend LLVM 13, but we should move to LLVM 15/16 soon.
Let's close this one -- I created #1703 to add support for freeze