[LLVMdev] LLVM and libc

Pertti Kellomäki pk at cs.tut.fi
Mon Nov 6 12:16:12 PST 2006


I have been browsing through the newlib documentation at
<http://sources.redhat.com/newlib/> and pondering about
how newlib relates to LLVM. Comments welcome, again.

As I see it, there are basically two parts of libc that need to be
considered. Much of libc is stuff like atoi(), isalpha(), etc. which are
just convenience routines written in ANSI C. For these, it should be
sufficient to compile them with llvm-gcc, and link them at the
LLVM bytecode level. This is basically what is done at
$(LLVM)/runtime/GCCLibraries/libc.

The target specific stuff has mostly to do with system calls. Many
system calls do not make sense in an embedded context, so newlib
includes a suite of no-op stubs that one can use. For a minimal
functionality, one can define read() and write() e.g. to operate on
the serial port.

To me, the most sensible approach would be to port newlib to
the LLVM virtual machine, and use LLVM intrinsic functions
as placeholders for the actual system calls. The back end
would then emit target specific code for the intrinsics.

What I don't quite see is how crt0 fits in the picture. Am I
right in assuming that when llvm-gcc emits LLVM byte code, there
is no crt0 involved? I haven't checked how the other back ends
do it, but I assume that they rely on the host libc and crt0.
In my case, I envision libc being linked in at the bytecode
level, and crt0 being linked in by the back end.

Does this sound like a sensible approach?
-- 
Pertti



More information about the llvm-dev mailing list