OSDev.org

I've read the OSDev articles on cross compilers (what they are, why they're needed, etc), and have some specific questions, as I felt the articles were a bit vague. In general, I didn't understand the following: "You won't want the default libraries such as libc, because the user-space versions are not suitable for kernel use". Why exactly is that, and how does this cross compiler work without the C standard library? If this is true is it possible to use something like EmbToolkit to generate a cross compiler? I ask because I know embtoolkit creates a toolchain with a c standard library implementation (either GNU or musk, I believe). Also, why do you have to treat compiling for kernelspace and compiling for userspace differently (passing -ffrestanding)? Lastly, besides issues with reproducing builds, what sorts of compilation errors can compiling with your system compiler cause? I know that this sort of compilation will use system specific definitions, but does anyone have concrete examples of why that's bad? Thanks!

Simply put, a usermode application and one built for bare bones computing are wildly different. A usermode application will depend on system calls to an operating system to run, and obviously you can't do that when you are writing your own kernel. A bare bones one has nothing else other than itself, and is dependent on nothing but the hardware. Your system compiler will probably try to link libraries that depend on Linux and other things that depend on being in userspace. So, you need to make sure this doesn't happen, like ever. The C standard library depends on system calls to the operating system you are running; thus you can't have it (well, some DO go even to bare bones). You see, there is NO NOTHING when you are doing your OS. Everything is made BY you. Now you probably can't use EmbToolkit to make a cross compiler, since they only support ARM and MIPS architectures, and is only used in embedded systems.

Hi mango,

The cross-compiler itself uses the standard library of your host Linux environment (or whatever) so itself can run. However, the programs that it produces doesn't use the Linux libc of your host environment. That is the cross part: It runs in one environment, but creates executables for another environment. The cross-compiler itself is just a normal Linux program, but what it produces isn't.

There is such a thing as System Calls (which is a core operating system concept). Processes make system calls, which cause the CPU to transfer execution to the kernel system call handler, which services them and returns to the process when done. This is how normal programs function, they can't do a lot of things due to advanced memory protection in the operating system, so they politely ask the kernel do to it for them. However, when you are the kernel (as you are in osdev), there is no one to service these calls: You have to do everything yourself by communicating with the hardware and executing special system instructions (which you can do, unlike normal processes, because you execute in kernel mode).

The Linux standard library (libc) relies on system calls for a number of tasks. This makes it unusable for kernel use. Additionally, it is usually a dynamically linked executable, which is also unavailable in the kernel mode (there is no dynamic linker). We treat compiling in kernel mode differently because it is. The -ffreestanding does a few good useful things by letting the kernel know it isn't compiling a normal program.

You can potentially osdev without a cross-compiler. It leads to various kinds of trouble, which is fairly easily avoided with a bunch of compiler options. However, all they do is attempt to make your compiler like a cross-compiler, but in a poor and fragile fashion. The most common problem is that you end up using headers from /usr/include and libraries from /usr/lib, and so you disable that, but now you can't use the headers that the compiler provides. Basically, you can remove a heap of trouble and hacks by using a cross-compiler. It's really about 1) Letting the compiler understand what is going on 2) Avoiding ugly hacks in your operating system by investing a little time in building a cross-compiler.

Thanks for the replies! I knew the bit about system calls, but I had no idea that dynamic linking was unavailable. Thanks!

Remember, you got NOTHING when you make your OS; only what you provide yourself. I remember talking to some guy about OS development; it was amusing (and a little concerning) when he got shocked that malloc was unavailable . Don't be him .