Purpose:
I implemented a pass on LLVM backend that changes the output format of ARM assembly/binary (e.g add a jump at the end of each basic block to eliminate fall through). By calling:
llc -march=arm somefile.bc
it generates expected arm assembly/binary that runs properly on arm gnu linux (I use qemu-arm and gem5 to simulate it). Now I want to do the same thing on standard c library, but here are problems.
Problems:
According to:
http://article.gmane.org/gmane.comp.compilers.llvm.devel/77025
https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_14/docs/OpenProjects.html#glibc
compiling glibc using llvm may not be a proper option. On the other hand, according to:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2012-January/047088.html
llvm could be able to compile newlib, thus people consider newlib as an alternative. However, according to:
http://www.embecosm.com/appnotes/ean9/ean9-howto-newlib-1.0.html#id2711887
newlib intends to support binaries for bare metal (no OS) software. It implements only the hardware independent parts (e.g libc and libm) and leave a stub for each hardware dependent syscall (e.g everything in libgloss).
In fact I tried to compile a simple "hello world" c program using arm-none-eabi-gcc which was configured with "--with-newlib" option, the program execution ends up with segmentation faults on both qemu-arm and gem5.
Questions:
I'm not sure if the newlib is compatible with glibc. I'm wondering if I could use llvm to cross-compile the machine independent parts (at the same time change the arm output format) from newlib and use arm-none-linux-gnueabi-gcc to cross-compile the machine dependent parts from glibc and put these two parts together to generate my own standard c library?
There might be mistakes/misunderstandings in my work. Are there any other possible methods that could add my changes to at least part of the standard c libraries, and make the program run on qemu-arm or gem5?
