eurecom-s3 / symcc

SymCC: efficient compiler-based symbolic execution
http://www.s3.eurecom.fr/tools/symbolic_execution/symcc.html
GNU General Public License v3.0
776 stars 135 forks source link

Dockerfile fails #22

Closed vanhauser-thc closed 3 years ago

vanhauser-thc commented 3 years ago

Building a container from scratch fails:

$ docker build -t symcc .
[...]
[12/14] Building CXX object CMakeFiles/Symbolize.dir/compiler/Symbolizer.cpp.o
[13/14] Linking CXX shared module libSymbolize.so
[13/14] Testing the system...
-- Testing: 16 tests, 16 workers --
FAIL: compiler :: structs.c (1 of 16)
******************** TEST 'compiler :: structs.c' FAILED ********************
Script:
--
: 'RUN: at line 15';   /symcc_build_simple/test/../symcc -O2 /symcc_source/test/structs.c -o /symcc_build_simple/test/Output/structs.c.tmp
: 'RUN: at line 16';   echo -ne "\x00\x00\x00\x05" | /symcc_build_simple/test/Output/structs.c.tmp 2>&1 | FileCheck --check-prefix=SIMPLE --check-prefix=ANY /symcc_source/test/structs.c
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 15"
$ "/symcc_build_simple/test/../symcc" "-O2" "/symcc_source/test/structs.c" "-o" "/symcc_build_simple/test/Output/structs.c.tmp"
# command stderr:
Warning: losing track of symbolic expressions at inline assembly   %22 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %16) #4, !srcloc !8
[...]
sebastianpoeplau commented 3 years ago

I should really set up automated container builds... Will look into it.

wideglide commented 3 years ago

seems like endianness ba36649a57b05b2e0285db70d4075008af678e4d changes are the culprit

#9 254.7 FAIL: compiler :: loop.c (6 of 16)
#9 254.7 # command stderr:
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %22 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %16) #5, !srcloc !8
#9 254.7 FAIL: compiler :: pointers.c (8 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %25 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %19) #4, !srcloc !8
#9 254.7 FAIL: compiler :: switch.c (9 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %23 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %17) #4, !srcloc !8
#9 254.7 FAIL: compiler :: structs.c (12 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %22 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %16) #4, !srcloc !8
#9 254.7 FAIL: compiler :: file_input.c (13 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %33 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %27) #4, !srcloc !8
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %120 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %114) #4, !srcloc !9
#9 254.7 FAIL: compiler :: memcpy.c (15 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %26 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %20) #4, !srcloc !8
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %49 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %43) #4, !srcloc !9
#9 254.7 Warning: losing track of symbolic expressions at inline assembly   %72 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %66) #4, !srcloc !10
#9 255.0 Failing Tests (7):
#9 255.0     compiler :: file_input.c
#9 255.0     compiler :: globals.c
#9 255.0     compiler :: loop.c
#9 255.0     compiler :: memcpy.c
#9 255.0     compiler :: pointers.c
#9 255.0     compiler :: structs.c
#9 255.0     compiler :: switch.c
sebastianpoeplau commented 3 years ago

With that change we started to pass test inputs in big-endian order, which is then converted with ntohl and friends if necessary. Probably that function translates to inline assembly in our Ubuntu container. Let's see if passing little-endian inputs fixes the issue - then the tests may run into problems on big-endian machines, but I assume it's very rare for people to have such systems while x86 is overwhelmingly common...