I’m trying to generate whole program bitcode files for linux kernel and do interprocedural analysis on kernel.
I use llvmlinux to compile kernel with clang and generate a bunch of bitcode files successfully.
I need to link all these bitcode files together into a single bitcode file, so that I can run whole program analysis.
Should I use libLTO to link all these bitcode files together? I guess I have to modify the linux kernel’s build scripts and Makefiles?
I’m kind of confused. Any suggestions?
There are two ways to do it. First, you can use llvm-link to link the bitcode files together. This will require some manual changes to the Linux Makefiles. Once you get a single bitcode file, you can run your analysis pass via opt. This is the approach that I used for the original SVA system for Linux 2.4.22 back before we had libLTO. Second, you could add your pass to libLTO and change the Linux Makefiles to use the -flto option. This method should require fewer Makefile changes but will require you to build and install your own libLTO library. Regards, John Criswell
First, you can use llvm-link to link the bitcode files together. This
will require some manual changes to the Linux Makefiles. Once you get a
single bitcode file, you can run your analysis pass via opt. This is the
approach that I used for the original SVA system for Linux 2.4.22 back
before we had libLTO.
When we first started investigating the feasibility of LTO on our target,
in order to avoid having to change build systems, we replaced our linker
executable with a python script that called llvm-link, opt, llc, and the
original linker. The only build system change required was to add -flto to
the compiler command line options. This worked surprisingly well as a
first attempt. Depending on how invasive the Makefiles changes would be,
this method may be simpler for your purposes, although if you're able to
use libLTO that would be simpler still. Gao's lightning talk "*Link-Time
Optimization without Linker Support" *from the 2013 developer meeting goes
into more detail of the approach: The LLVM Compiler Infrastructure Project
First, you can use llvm-link to link the bitcode files together. This will require some manual changes to the Linux Makefiles. Once you get a single bitcode file, you can run your analysis pass via opt. This is the approach that I used for the original SVA system for Linux 2.4.22 back before we had libLTO.
When I generate bitcode files, I pass -emit-llvm flag to compiler command line ( clang -emit-llvm “a long list of parms” *.c ) so that it generates .bc files during compilation. Since -emit-llvm doesn’t change the name of file output, I rename *.o file to *.bc file.
Then I run compiler again ( clang “a long list of parms” *.c ) to generate *.o file otherwise Kbuild would break. So basically I create *.bc files next to all the *.o files (where possible)
How should I modify Makefiles to link all the bitcode files together? Could you share with me some experience?
My guess is to use llvm-link to link bitcode files along with every ld command line?
For example,
For " ld -r -o init/mounts.o init/do_mounts.o init/do_mounts_initrd.o init/do_mounts_md.o; "
I’ll have something like " llvm-link -o init/mounts.bc init/do_mounts.bc init/do_mounts_initrd.bc init/do_mounts_md.bc; " ?
I got a link error when I’m trying to use llvm-link to link all those bitcode files.
For example,
AS usr/initramfs_data.o LD usr/built-in.o
initramfs_data.o is generated by initramfs_data.S, and ld links initramfs_data.o to build-in.o.
But clang can not generate bitcode file “initramfs_data.bc” from initramfs_data.S. When I use llvm-link to link initramfs_data.bc to built-in.bc, an error comes out because initramfs_data.bc is missing.
Any suggestions? Is it possible that clang can compile *.S to *.bc? If not, how should I get rid of the missing bitcode file?