Hi! This week I have been working on LLVM\/Clang support for
\nCrossdev. This is currently done by swapping out the different Crossdev
\nstages for ones that make sense for LLVM.<\/p>\n
Currently it replaces stage0 with checking whether LLVM can target the
\ntarget triple’s architecture by checking the LLVM_TARGETS USE-flag.<\/p>\n
Stage1, which normally installs libc headers and compiles a -stage1 C
\ncompiler is replaced by installing libc headers and compiling
\ncompiler-rt.<\/p>\n
Stage2 (kernel headers), is the same.<\/p>\n
Stage3 (libc install), is the same.<\/p>\n
Stage4, which compiles a full compiler is skipped completely.<\/p>\n
Another needed change was to make the compiler-rt ebuild cross-aware,
\nwith changes like making the assembler and C compiler target the target triple, and
\nincluding headers from the crossdev \/usr\/${CTARGET}\/usr\/include
\ndirectory instead of using the host’s libc headers. I got some help from
\nwikky here, thanks!<\/p>\n
Currently doing ‘crossdev –llvm -t riscv64-gentoo-linux-musl &&
\nriscv64-gentoo-linux-musl-emerge dash’ produces a working binary that
\ncan be run using qemu-user like this ‘qemu-riscv64 -L
\n\/usr\/riscv64-gentoo-linux-musl \/usr\/riscv64-gentoo-linux-musl\/bin\/dash’
\nwhich I think is very cool! However, there is still some issues with
\ndynamically linking libraries built with the cross compiler. For example
\nxz-utils installs liblzma.so which fails with “exec format
\nerror”. (http:\/\/sprunge.us\/HkSmms). I am currently looking into that.<\/p>\n
Another thing I’m still a little uncertain about is where to put all
\nenvironment variables and compilation options, whether it’s crossdev’s
\njob or the ebuilds’. This is something I will come back to, and I have
\nsome changes locally on my computer
\nCrossdev patches:
\nhttps:\/\/github.com\/alfredfo\/crossdev\/commit\/ec65dee4b4c359bf3e0fc374d31e05b147fa3f0d
\nCompiler-rt patches:
\nhttps:\/\/github.com\/alfredfo\/catcream_repo\/blob\/master\/sys-libs\/compiler-rt\/compiler-rt-17.0.0.9999.ebuild<\/p>\n
Later during the week I made ebuilds for LLVM libc and
\nlibc-hdrgen (generates LLVM libc headers from TableGen specification
\nfiles). Normally you build LLVM libc together with libc-hdrgen, but when
\ncross compiling it’s a better idea to split these and keep libc-hdrgen a
\ntool installed on the build host. I have played with only building
\nlibc headers for bootstrapping with crossdev but I haven’t figured it all out yet.
\nTo only install headers you can use the install-libc-headers target, but
\nit seems like CMake still wants to build things. There’s also the scudo
\nallocator that needs to be statically linked to LLVM libc. My idea is to
\nmake a USE=static-scudo flag for compiler-rt that gets set in crossdev
\nwhen compiling compiler-rt for a LLVM libc target.
\nThese are also kept locally until I’ve figured out how to cross compile
\nin stages.<\/p>\n
Many “small random issues” and technicalities have also poped up during
\nthis week that’ve taken quite a long time, but are not really worth
\ndigging into here.<\/p>\n
Next week I will continue with this until I can use it to work on LLVM
\nlibc, worst case scenario I could temporarily make a “franken LLVM libc ebuild” that
\ndoes everything (headers, compiler-rt, scudo, llvm libc) in one shot,
\nbut it should definitely be possible to do it separately.<\/p>\n
I also forgot to update my llvm-common changes with the new
\nelisp-site-file-install function that was inspired by my PR \ud83d\ude41
\n… will fix that tomorrow.<\/p>\n
Thanks for reading!<\/p>\n","protected":false},"excerpt":{"rendered":"
Hi! This week I have been working on LLVM\/Clang support for Crossdev. This is currently done by swapping out the different Crossdev stages for ones that make sense for LLVM. Currently it replaces stage0 with checking whether LLVM can target … Continue reading