C++: Difference between revisions

By default, G++ attempts to link in startup code - the stuff usually done before main() is called, and after it exits / returns. This is all fine in a hosted environment, but you don't want to have it in your kernel (and it would not compile, either). Disable this by setting -nostartfiles.

If you want to use pure virtual functions, your compiler needs one support function. It is only called in case a pure virtual function call cannot be made (e.g. if you have overriden the virtual function table of an object). But nonetheless your linker will complain about unresolved symbols, if you use pure virtual functions and don't provide that support routine.

Before you can use new and delete, you have to implement some memory management, and the operator new() and operator delete() functions (including their array counterparts).

Note: the option -ffreestanding, usually recommended in kernel tutorials, cannot be used with G++.

Run-time type information is used for typeid and dynamic_cast, and requires run-time support as well. Disable it with -fno-rtti.

Note that RTTI is required for some C++ features. If you disable it, you won't be able to use typeid or dynamic_cast. Virtual functions should work without RTTI, though.

Another feature that requires run-time support. Disable them with -fno-exceptions.

Global or static objects have to be constructed by the environment before they are available for C++ code. Care should be taken if global/static objects need new and delete in their constructors. In this case it is best to construct global/static objects only after your kernel heap is ready for use. Not doing so can cause an object to attempt to allocate memory via the non-working new operator. This also simplifies the storing of the destructor functions in __cxa_atexit, because you don't have to use a static and fixed-size structure.

:GCC 4.0.2 seems to follow the same convention as GCC versions below 3.2. This seems to be independent of what is given with -fabi-version. I do get a dtors section.

f is a function-pointer to the destructor, p is the parameter for the destructor and d is the "home DSO" (DSO = dynamic shared object). This function should save all three parameters and if successful return zero, on failure nonzero. When your kernel exits you should call

with d = 0 in order to destroy all with __cxa_atexit registered objects. Objects, which were registered first with __cxa_atexit, must be destroyed last by __cxa_finalize. You must provide the symbol __dso_handle in your executable. Only the address of this symbol is needed, because GCC calls __cxa_atexit with &__dso_handle.

Running constructors and destructors is covered in MSDN help and in the C runtime library sources. See #pragma init_seg on MSDN for some more information.

Basically what happens is that pointers to functions are placed in .CRT$XIC, $XIL, $XIU based on the value of init_seg. The linker then merges everything together in the .CRT section, in the order of the letters after the $. The pointers between the XIA (xi_a) and XIZ (xi_z) are then called if nonzero. The .CRT section is merged with the .data section to avoid a whole separate section.

One problem with C++ support is the horrible name-mangling that is impossible to read in the map file. A build script should be set up that runs the map file through the undname.exe tool, so that names like ??2@YAPAXI@Z (operator new - I think...) and others are readable.

Here is some code. Sorry for its length, but it is hard to explain any other way. Simply call runInit() when you want to initialize any static objects and then call runTerm() when static object destructors are to be run.

Everytime you call one of the operators new(), new[](), delete(), or delete[](), the compiler inserts a call to them. The most simple implementation would be to map them to kmalloc() / kfree():

Note that new should actually use kcalloc (allocate and zero) otherwise the variables will be filled with garbage which you will then need to clear manually

Note the use of the "operator" keyword. A nice option is that new() can be overloaded (non-standard but potentially useful).

GCC sometimes emits code that calls operator delete even when you haven't used delete yourself. It seems to sometimes emit a "normal" version of a destructor and a separate version for delete. So you might need to define operator delete even before you have kmalloc:

This won't be called until you use new/delete, but it might be needed for linking. This problem seems to appear when classes with pure virtual functions are used.

In C++, and especially in OS code where structures can be found at fixed addresses, it can be useful to construct an object in memory obtained elsewhere. This is accomplished through a technique known as placement new. As an example, say you wanted to create an APIC object at address 0x09fff0000. This snippet of code will use placement new to do the trick: