Error raised when running "ninja check-mctoll"

[leibo-hust]

When running the command “ninjia check-mctoll”, i meet a problem that different from the Issue #53, and i tried many methods but that didn't work, so i have to ask you for help. The problem i met is that i couldn't pass the check, 12 Unexpected Failures occur， and the the reasons for failures are all as follow:
FAIL: mctoll :: smoke_test/ARM/factorial-test.c (36 of 145)
******************** TEST 'mctoll :: smoke_test/ARM/factorial-test.c' FAILED ********************
Script:

: 'RUN: at line 1'; /home/user02/CGCL/llvm-mctoll/llvm-project/build/bin/clang /home/user02/CGCL/llvm-mctoll/llvm-project/llvm/tools/llvm-mctoll/test/smoke_test/ARM/../Inputs/factorial.c -o /home/user02/CGCL/llvm-mctoll/llvm-project/build/tools/llvm-mctoll/test/smoke_test/ARM/Output/factorial-test.c.tmp.so --target=arm-linux-gnueabi -fuse-ld=lld -shared
: 'RUN: at line 2'; /home/user02/CGCL/llvm-mctoll/llvm-project/build/bin/llvm-mctoll -d /home/user02/CGCL/llvm-mctoll/llvm-project/build/tools/llvm-mctoll/test/smoke_test/ARM/Output/factorial-test.c.tmp.so
: 'RUN: at line 3'; /home/user02/CGCL/llvm-mctoll/llvm-project/build/bin/clang -o /home/user02/CGCL/llvm-mctoll/llvm-project/build/tools/llvm-mctoll/test/smoke_test/ARM/Output/factorial-test.c.tmp1 /home/user02/CGCL/llvm-mctoll/llvm-project/llvm/tools/llvm-mctoll/test/smoke_test/ARM/factorial-test.c /home/user02/CGCL/llvm-mctoll/llvm-project/build/tools/llvm-mctoll/test/smoke_test/ARM/Output/factorial-test.c.tmp-dis.ll -mx32
: 'RUN: at line 4'; /home/user02/CGCL/llvm-mctoll/llvm-project/build/tools/llvm-mctoll/test/smoke_test/ARM/Output/factorial-test.c.tmp1 2>&1 | /home/user02/CGCL/llvm-mctoll/llvm-project/build/bin/FileCheck /home/user02/CGCL/llvm-mctoll/llvm-project/llvm/tools/llvm-mctoll/test/smoke_test/ARM/factorial-test.c

Exit Code: 1

Command Output (stderr):

ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbeginS.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtendS.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang-11: error: linker command failed with exit code 1 (use -v to see invocation)

I think is the ld.lld's problem, but I don't know how to slove it, and i don't know whether this will influence the result of the llvm-mctoll. Any help would be appreciated! Thanks a lot!

[bharadwajy]

Thanks for your interest in using the tool.

It appears that you may not have the necessary ARM tools for ARM binary tests to run. The tool should have been built as expected and should be usable.

[leibo-hust]

Thanks a lot! I have another question, does this will affect the result of the llvm-mctoll that translate binary to IR. I use the llvm-mctoll to translate the a.out of factorial.c to the IR, but the result IR of funciton factorial(n) is different from the the result in the paper you have published, and also different from the source file(factorial.c) to the IR. So I don't know where is the problem. Thanks again!

[leibo-hust]

my source file f.c is:
#include <stdio.h>

int factorial(int n) {
if (n == 0) {
return 1;
}
return n * factorial(n - 1);
}

int main()
{

int n = factorial(10);
printf("%d\n", n);

return 0;

}

And the f.out-dis.ll file is:
define dso_local i32 @factorial(i32 %arg1) {
entry:
%stktop_8 = alloca i8, i32 24, align 1
%RSPAdj_N.16 = bitcast i8* %stktop_8 to i64*
%tos = ptrtoint i8* %stktop_8 to i64
%0 = add i64 %tos, 16
%RBP_N.8 = inttoptr i64 %0 to i32*
%1 = add i64 %tos, 20
%RBP_N.4 = inttoptr i64 %1 to i32*
%2 = add i64 %tos, 0
%RSP_P.0 = inttoptr i64 %2 to i64*
%RBP = ptrtoint i64* %RSP_P.0 to i64
store i32 %arg1, i32* %RBP_N.8, align 4
%3 = load i32, i32* %RBP_N.8, align 1
%4 = zext i32 %3 to i64
%5 = zext i32 0 to i64
%6 = sub i64 %4, %5
%7 = call { i64, i1 } @llvm.usub.with.overflow.i64(i64 %4, i64 %5)
%CF = extractvalue { i64, i1 } %7, 1
%ZF = icmp eq i64 %6, 0
%highbit = and i64 -9223372036854775808, %6
%SF = icmp ne i64 %highbit, 0
%8 = call { i64, i1 } @llvm.ssub.with.overflow.i64(i64 %4, i64 %5)
%OF = extractvalue { i64, i1 } %8, 1
%CmpZF_JNE = icmp eq i1 %ZF, false
br i1 %CmpZF_JNE, label %bb.2, label %bb.1

bb.1: ; preds = %entry
store i32 1, i32* %RBP_N.4, align 4
br label %bb.3
.........................................

which is different from the result in the paper: 《Raising Binaries to LLVM IR with MCTOLL
(WIP Paper)》

[bharadwajy]

Thanks a lot! I have another question, does this will affect the result of the llvm-mctoll that translate binary to IR. I use the llvm-mctoll to translate the a.out of factorial.c to the IR, but the result IR of funciton factorial(n) is different from the the result in the paper you have published, and also different from the source file(factorial.c) to the IR. So I don't know where is the problem. Thanks again!

I am assuming that you are referring to an x86-64 factorial binary (since your reference to the paper).

It appears that all x86-64 binary raising tests pass with the tool built by you. Failure of ARM tests due to apparent missing ARM tools, has no affect on the llvm-mctoll built.

There have been several enhancements to the tool since the paper was written. Hence, it is not unexpected that the generated LLVM IR for factorial.c is different from that in the paper. It is important that the generated LLVM IR is functionally correct. You can verify the correctness of the LLVM IR generated for factorial binary by compiling it using clang and running the resulting binary.
Please feel free to file a detailed bug report for any errors in executing the resulting binary, if found.

Thanks!

[leibo-hust]

Thanks very much!
Actually, I have did that before, the output of the f-dis.out is right, but the IR is different with that in your paper, so I was puzzled. Thanks again!

However, when I testing another c source file, the result is wrong. I want to write a new issue so the other people could see this. Thanks!

[bharadwajy]

Add changes (9a38eaf ) that check for the availability of ARM cross tools needed for ARM raising tests and gracefully avoid when they are not available on the test machine.