Using Clang instead of GCC?

[quanganht]

Hi,
According to Clang and LLVM documentations, they are far better than GCC in compiling time, speed of generted code, expressive messages...and sound like a perfect compiler for C/C++. What I'm thinking is: Is it good to use Clang/LLVM for OS development? Can they replace GCC? How can I build a cross-compiler out of the source?
Looking forward for your opinions.
QA

[JamesM]

Hi,

Clang and LLVM certainly are of good quality - the code generation for Intel isn't *quite* up to the standard of GCC yet, but it's certainly getting there at a fast rate and to be honest, you're unlikely to see the difference.

With Clang and LLVM you don't actually need a cross-compiler. Clang can generate LLVM bitcode for you to compile and link yourself ("-emit-llvm"), or can invoke LLVM itself and generate an object file ("-c -o myobj.o") - exactly the same as GCC.

Once you have your object files, you can link them with whatever tool you wish - llvm has its own linker, or you can use GNU LD as you currently do. LLVM isn't as hard-tied to the platform's glibc, so you don't need a cross compiler.

Hope this helps,

James

[quanganht]

Thanks for the reply

Once you have your object files, you can link them with whatever tool you wish - llvm has its own linker, or you can use GNU LD as you currently do. LLVM isn't as hard-tied to the platform's glibc, so you don't need a cross compiler.

So that means machine code produced by llvm linker can run without glibc and/or standard libs? I prefer llvm linker because it can do cross-file optimizations.

Edit: I saw llvm-ld have an command line option named "-native", which instructs llvm-ld to generate native executable. Do we have to concern about it?

[JamesM]

Hi,

You can of course keep everything in LLVM bitcode form for the final link - this enabled LLVM to do its link-time optimisations.

You will at some point still need to generate machine code - this is done using "llc", which takes an LLVM bitcode file and spits out an assembly (GNU as format) file that you must then assemble.

Cheers,

James

[Fanael]

I prefer llvm linker because it can do cross-file optimizations.

So you're using an outdated version of GCC. Upgrade it unless you have good reason to not do so.

[Owen]

I prefer llvm linker because it can do cross-file optimizations.

So you're using an outdated version of GCC. Upgrade it unless you have good reason to not do so.

GCC's cross file optimizations require the GOLD linker, which is pretty rare. Additionally, GCC LTO is well known for being buggy and breaking lots of code.

[Fanael]

GCC's cross file optimizations require the GOLD linker, which is pretty rare.

It doesn't (actually, it does, but only for archives) - if it requires GOLD (ELF-only linker), how does it work under Windows (which uses PE/COFF) and Mac OS (Mach-O)?

Additionally, GCC LTO is well known for being buggy and breaking lots of code.

You can remove "LTO" from this sentence and it'll still be true (well, at least the part about being buggy)

[quanganht]

You will at some point still need to generate machine code - this is done using "llc", which takes an LLVM bitcode file and spits out an assembly (GNU as format) file that you must then assemble.

There's no way to emit an executable directly from llvm?

[quanganht]

Thanks guys for your help. I will give LLVM a try

[JamesM]

Thanks guys for your help. I will give LLVM a try

Hi,

You asked about keeping the intermediate files in LLVM bitcode format instead of ELF partially-linked .o. You can do that, but the front-end driver cannot then generate the executable using the same command line as GCC would - you have to use the "llc" tool (which comes with LLVM - it's just a driver front end!) to generate the executable.

So yes, it's still done "inside of LLVM".

James

[quanganht]

Hmmm, clang man page says "Clang currently does not have C++ support..." while on its website it is said to support all iso c++ 98 standards
And i still find the building process quite confusing, because I have to put assembly (Intel syntax),C and C++ code together. Cannot get an executable yet.

[Solar]

...because I have to put assembly (Intel syntax),C and C++ code together.

OT: Definitely one language too many. If you're doing C++, there's no reason to have C files since there's always extern "C" if necessary. (Virtually any decent C can be compiled with a C++ compiler(*), with minimal changes if need be, reducing the number of languages used, which is A Good Thing.)

(*) And because I cannot resist the temptation for my favourite flame angle, this goes to prove that the Linux kernel is not decent C. On purpose.

[JamesM]

Hmmm, clang man page says "Clang currently does not have C++ support..." while on its website it is said to support all iso c++ 98 standards
And i still find the building process quite confusing, because I have to put assembly (Intel syntax),C and C++ code together. Cannot get an executable yet.

Why is that a problem? Compile everything to .o with clang straight away then.

Or, if you still want LTO, compile everything with clang or llvm-gcc to LLVM bitcode except the assembly, link it, "llc" it to create a partially-linked object file (standard .o), then link that with GNU ld with your assembly.

Magic.

[quanganht]

What's happening right now is output object files from clang is not recognized by gnu ld

Code: Select all

~clang -c -nostdlib -nodefaultlibs -mcmodel=large Kernel.cpp -o Kernel.o
~nasm -f elf loader.asm -o loader.o
~i586-elf-ld -T link.ld -o Kernel .bin loader.o Kernel.o
Kernel.o: file not recognized: File format not recognized

Edit: Maybe something is wrong with my toolchain. Like JamesM said, I used llc to get an assembly file (Kernel.s) then compile it with gnu as

Code: Select all

as Kernel.s -o Kernel.o

But when I try to link, the same error appears.

Edit2: found it. llc emitted 64-bit asm code. But adding "-march=x86" to llc makes it spit out broken code

[Owen]

Hang on - "-mcmodel=large" implies 64-bit code. Additionally, since you're not passing an architecture specification to clang, it will produce native code for your platform (presumably, x86_64). You need to make clang emit 32-bit code too.

LLVM bitcode generated from C(++) is not portable; too much information has been discarded