C++ ABI in your OS

[lpcstr]

So I was thinking about what it would be like to write an operating system primarily in C++ and using a C++ API. If I'm not mistaken, this could be problematic, as the C++ ABI is not as stable as the C ABI. For instance, if you compile your kernel and the rest of your OS and user mode applications with lets say, GCC 4.4, then later on down the road, you decide you want to update GCC to a newer version, you may very well have to recompile the entire OS and all your program. Isn't that the case?

That would make your compiler a very integral part of your OS.

[gerryg400]

Don't confuse the kernel ABI and a compiler/language ABI. At its core, the kernel ABI, that is the means of calling kernel services, ought to be quite language independent.

In most cases the kernel ABI is processor dependant (e.g. i386 might be to push parameters onto stack and do software int or syscall/sysenter) and is written in assembler. Wrappers in C or C++ are then required to access the kernel from applications. The wrappers live in user space and can be re-written without modifying the kernel.

[lpcstr]

I guess I didn't think things through clearly. You might not need to recompile your kernel when you upgrade your compiler, but you would need to compile a separate set of libraries for your user mode applications. That, or recompile everything but the kernel.

[bluemoon]

Instead of recompile library, I would think in other direction.

Test the library with your choice of supported compilers and versions. Followup actions (ie. compile a new set of the libraries) is only taken if the tests failed.
Most compiler won't change the inner works in minor updates so you don't need to recompile and maintain many set of libraries for every compiler versions.

Even you supply the source code of glue library for them to compiles, you still want to test it before you tell the user which compiler and version they may use.