Using Clang instead of GCC?

[Owen]

LLVM bitcode is in essence assembly language. Haven't seen a portable assembly yet.

LLVM bitcode is. However, post preprocessing, [standard] C isn't

[JamesM]

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

Doesn't 'as' normally default to a.out output, not ELF? Run;

Code: Select all

file Kernel.o

and see what you get.

[Solar]

Run;

Code: Select all

file Kernel.o

and see what you get.

+ {INF}.

Whenever your toolchain complains about formats, use "file" to figure out what the format in question actually is, instead of guessing...

[JamesM]

"file" is one of the most useful and seemingly underused utilities in the UNIX operating system.

[fronty]

Doesn't 'as' normally default to a.out output, not ELF?

Don't know about Linux, but on every system I'm familiar with as outputs same format that is used by other parts of toolchain. ELF that is these days.

[JamesM]

Doesn't 'as' normally default to a.out output, not ELF?

Don't know about Linux, but on every system I'm familiar with as outputs same format that is used by other parts of toolchain. ELF that is these days.

Just checked, you're quite right.

[Mohanty]

Though Clang and llvm have good documentation, Still it is not well known till now as like GCC. and till now it is not accepted by most user.

so If u find some bug in OS development using Clang then There is no one to help u. So there will be delay in Development.

So In my view it is better to work through GCC. Otherwise Improved version of GCC is also very faster...

[Solar]

so If u find some bug in OS development using Clang then There is no one to help u. So there will be delay in Development.

Good luck getting support from the GCC team if your bug is specific to OS development...

[NickJohnson]

@SatyaNarayan: I use Clang (compiling directly to x86 machine code; I haven't tried LLVM LTO or anything), and it compiles my whole project just fine. The Clang project seems a lot cleaner than GCC - I wouldn't be surprised if bug reports were processed faster for Clang, despite the fact that not as many people use it. Clang's -O3 is also noticeably faster than GCC's -O3, both for compile time and run time, and most benchmarks confirm that.

If only I could get Gentoo to use it as a system compiler...

[Love4Boobies]

Thought I'd make a small correction...

LLVM isn't as hard-tied to the platform's glibc, so you don't need a cross compiler.

The standard library isn't the reason for which people build GCC cross-compilers. If they don't want to link it in, they can just use -ffree-standing. There are two reasons for building a cross-compiler: (1) the target(s) and (2) the ABI (i.e., any initialization prior to main, calling conventions, etc.).

[fronty]

so If u find some bug in OS development using Clang then There is no one to help u. So there will be delay in

Clang has many active developers who will be very willing to fix bugs. There's a big company with paid developers working on it, I think it cares about bugs in clang and llvm, because they have it in production use.

[xyzzy]

so If u find some bug in OS development using Clang then There is no one to help u. So there will be delay in Development.

I've reported a couple of Clang bugs before, and had very fast fixes to them.