7

I have been using clang-3.5 to happily build bitcode versions of musl libc and use the result to produce nice stand alone executables.

Recent attempts with clang-3.8 have not been so happy. It seems that the bitcode clang-3.8 generates uses functions defined in

compiler-rt/lib/builtins

Typical examples of functions I find polluting the bitcode are mulxc3, mulsc3, and muldc3. I can solve this by linking against libgcc, or even the llvm alternative if I had any clear idea of what that was. Though I would rather prevent the problem from happening in the first place.

I have seen mention of flags like rtlib=compiler-rt etc, but have found precious little documentation on the subject.

So here are some simple questions.

  1. Is it possible to prevent clang from using the compiler-rt/lib/builtins in the emitted bitcode? Or if not

  2. Does llvm produce a version of libgcc that I could use. Actually I would probably build a bitcode version of it, but that is besides the point.

Love to hear some guidance on this.

Added 12/8/2016: So I will illustrate my issues with a particular workflow that people can reproduce if they wish, or, more likely, just point out where I am being stupid.

So start by checking out:

musllv

and follow the instructions in the README.to compile (here I am using clang-3.8 on ubuntu 14.04)

WLLVM_CONFIGURE_ONLY=1  CC=wllvm ./configure --target=LLVM --build=LLVM 
make
cd lib
extract-bc -b libc.a

you will also need the bitcode of a simple executable. I will use nweb.c here.

 wllvm nweb.c -o nweb
 extract-bc nweb

Now we can do things like:

clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb

This workflow goes smoothly for clang-3.5 but for clang-3.8 we get:

clang -static -nostdlib nweb.bc libc.a.bc crt1.o libc.a -o nweb
/tmp/libc-f734a3.o: In function `cpowl':
libc.a.bc:(.text+0xbb9a): undefined reference to `__mulxc3'
/tmp/libc-f734a3.o: In function `cpowf':
libc.a.bc:(.text+0x38f7d): undefined reference to `__mulsc3'
/tmp/libc-f734a3.o: In function `csqrt':
libc.a.bc:(.text+0x78fc3): undefined reference to `__muldc3'
/tmp/libc-f734a3.o: In function `cpow':
libc.a.bc:(.text+0xafafc): undefined reference to `__muldc3'
clang-3.8: error: linker command failed with exit code 1 (use -v to seeinvocation)

So as @paul-brannan points out we could try

clang -static -nostdlib --rtlib=compiler-rt nweb.bc libc.a.bc crt1.o libc.a -o nweb

But this is where I am probably being stupid, because I get:

clang-3.8: warning: argument unused during compilation: '--rtlib=compiler-rt'

irregardless of whether I use it as a linking or compiling flag.

Ian A. Mason
  • 207
  • 3
  • 8
  • I don't know the answer to the question, but I believe this bug report is relevant: https://llvm.org/bugs/show_bug.cgi?id=16404 BTW, linking using --rtlib=compiler-rt solved my linking problems looking for __muloti4, while linking with libgcc did not. – Paul Brannan Dec 07 '16 at 16:48
  • Thanks for the tip @paul-brannan, looks 'can-o-wormish'. Still I do not seem to have the midas touch. I'll post a follow up so that people can duplicate my issue, and nurse me to the promised land. – Ian A. Mason Dec 08 '16 at 18:34
  • I'm adding this here, because while it doesn't answer my question it also seems relevant. [Build GNU-free executables with clang](https://blogs.gentoo.org/gsoc2016-native-clang/2016/05/31/build-gnu-free-executables-with-clang/) – Ian A. Mason Dec 12 '16 at 02:20

1 Answers1

0

OK so I finally managed to make headway on this. I built llvm-3.8.1 together with the compiler-rt project using wllvm and wllvm++.

One of the build products was libclang_rt.builtins-x86_64.a, and from this archive I was able to extract the bitcode module

libclang_rt.builtins-x86_64.bc

using the command: extract-bc -b libclang_rt.builtins-x86_64.a This bitcode module has definitions for those pesky instrinsics like __mulxc3, __mulsc3, and __muldc3.

Hallelujah!

Ian A. Mason
  • 207
  • 3
  • 8