Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"warning: Linking two modules of different target triples" when using KLEE via Docker with the --libc=uclibc option #1642

Open
YikeZhou opened this issue Jun 21, 2023 · 4 comments

Comments

@YikeZhou
Copy link

Description

I'm using KLEE 3.0 via Docker. I came across lots of unexpected warning messages like this:

warning: Linking two modules of different target triples: 'get_sign.bc' is 'x86_64-unknown-linux-gnu' whereas '__uClibc_main.os' is 'x86_64-pc-linux-gnu'

Manually specifying the target triple may solve this problem. I wonder if this could be fixed globally in the construction of a Docker image.

Steps to reproduce

First, pull the docker image down and start a fresh container.

$ docker pull klee/klee:3.0
$ docker run --rm -ti --ulimit='stack=-1:-1' klee/klee:3.0

Then we need to find some input for KLEE.
The program doesn't matter here. So I choose get_sign.c as an example.

$ cd ~/klee_src/examples/get_sign/
$ clang -I ../../include -emit-llvm -c -g -O0 -Xclang -disable-O0-optnone get_sign.c

Now we have the .bc file. We can invoke KLEE with the following command-line.

$ klee --libc=uclibc get_sign.bc

Note: I'm aware that the --libc=uclibc option is unnecessary here.
It is only used to illustrate the warnings caused by this option.

KLEE complains about the mismatching targets.

KLEE: NOTE: Using klee-uclibc : /tmp/klee_build130stp_z3/runtime/lib/klee-uclibc.bca
KLEE: output directory is "/home/klee/klee_src/examples/get_sign/klee-out-0"
KLEE: Using STP solver backend
KLEE: SAT solver: MiniSat
warning: Linking two modules of different target triples: 'get_sign.bc' is 'x86_64-unknown-linux-gnu' whereas '__uClibc_main.os' is 'x86_64-pc-linux-gnu'

warning: Linking two modules of different target triples: 'klee_overshift_check64_Debug+Asserts.bc' is 'x86_64-unknown-linux-gnu' whereas '__uClibc_main.os' is 'x86_64-pc-linux-gnu'

KLEE: WARNING: undefined reference to function: __syscall_rt_sigaction
KLEE: WARNING: undefined reference to function: fcntl
KLEE: WARNING: undefined reference to function: fstat
KLEE: WARNING: undefined reference to function: ioctl
KLEE: WARNING: undefined reference to function: open
KLEE: WARNING: undefined reference to function: write
KLEE: WARNING: undefined reference to function: kill (UNSAFE)!
KLEE: WARNING ONCE: calling external: ioctl(0, 21505, 94527241372272) at libc/termios/tcgetattr.c:43 12
KLEE: WARNING ONCE: calling __user_main with extra arguments.

KLEE: done: total instructions = 11973
KLEE: done: completed paths = 3
KLEE: done: partially completed paths = 0
KLEE: done: generated tests = 3

Platform

I'm running Docker (with the WSL 2 backend) on a Windows PC.

@MartinNowack
Copy link
Contributor

This is unfortunately a result of building uclibc (building with wllvm) differently than KLEE's bitcode files (building with clang directly).
As a result, the target triplets are slightly different:
'x86_64-unknown-linux-gnu' vs. 'x86_64-pc-linux-gnu'
In this case, they are compatible.

But it becomes a problem if bitcode files of different platforms/architectures are mixed that's why KLEE is warning about it.

@YikeZhou I'll close this issue but feel free to re-open it with related follow-up questions.

@ccadar
Copy link
Contributor

ccadar commented Jun 22, 2023

I think it would be an improvement in terms of usability to remove such warnings when they don't matter, but this is something that LLVM rather than KLEE warns about.

@251
Copy link
Contributor

251 commented Jun 22, 2023

I think you might get a fitting target triple when building klee-uclibc with:

$ make -j2 KLEE_CFLAGS="--target=x86_64-unknown-linux-gnu" 

@ccadar
Copy link
Contributor

ccadar commented Jun 22, 2023

That would be nice to try. Let's reopen this until we try.

@ccadar ccadar reopened this Jun 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants