OSDev.wiki

C++: Difference between revisions

Page Discussion

C++ (view source)

Revision as of 05:13, 9 June 2024

385 bytes removed ,  26 days ago
m
Bot: Replace deprecated source tag with syntaxhighlight
[unchecked revision][unchecked revision]
VisualWikitext
(The "start up code" section is inaccurate and this is already covered in Bare Bones.)
m (Bot: Replace deprecated source tag with syntaxhighlight)
 
(25 intermediate revisions by 11 users not shown)
Line 1:
:''For a quick tutorial on getting a bare bones C++ kernel running see [[C++Bare bare bonesBones]]''
 
A kernel can be programmed in C++, it is very similar to making a kernel in C, except that there are a few pitfalls you must take into account (runtime support, constructors, ...). This page will not list any (dis)advantages of this approach, but rather what you need to do to get things fired up.
 
A lot of features C++ offers can be used on-the-fly; they require no additional support or code to use them properly (e.g. templates, classes, inheritance, virtual functions). There are however other parts of C++ that do require runtime support, which will be discussed in this article.
 
== Introduction ==
 
If you have created a C++ kernel as documented in the [[Bare Bones]] article, then many C++ features are already available and work out the box. However, your kernel does not yet satisfy the ABI and you cannot be confident that the compiler will not emit problematic code, even if you stick to the intersection of C and C++. In particular, you may need to initialize further CPU state to enable the floating-point registers and instructions, as the compiler has every reason to think floating point registers and instructions are available by default.
 
However, the compiler will assume that all the C++ runtime support is available by default, however you are not linking in libsupc++ into your C++ kernel, which implements the necessary run-time support. This is why you are passing -fno-rtti and -fno-exceptions to your cross-compiler to let these runtime features are unavailable. Going further, you should link in libsupc++ into your kernel, but at the moment it's known to not be readily accessible to those starting out with operating systems development and the GCC build process doesn't cross-compile it properly for the bare -elf platforms by default.
 
You also need to call the global constructors as documented in [[Calling Global Constructors]] to satisfy the ABI requirement that the program initialization tasks are properly called.
 
== Pure virtual functions ==
 
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 overridden 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 this support routine. It is a C++ requirement to provide this back-up function.
If you want to use pure virtual functions, your compiler needs a single support function. It is only called in case a pure virtual function call cannot be made (e.g. if you have overridden 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 this support routine.
 
Enabling pure virtual functions in GCC is fairly straightforward. All you need to do is add the function below to one of your C++ source files (and make sure it is linked in). It is not necessary to declare this function first, the definition alone is good enough for GCC. The function itself doesn't even need to do anything (and it doesn't in most implementations), it just needs to be "there" just in case.
 
Below you will find an example of an implementation in respectively GCC and Visual C++.
 
<sourcesyntaxhighlight lang="cpp">
extern "C" void __cxa_pure_virtual()
{
// Do nothing or print an error message.
}
</syntaxhighlight>
</source>
 
Or, if you happen to use Visual Studio:
 
<sourcesyntaxhighlight lang="cpp">
int __cdecl _purecall()
{
// Do nothing or print an error message.
}
</syntaxhighlight>
</source>
 
If, during runtime, your kernel detects that a call to a pure virtual function couldn't be made, it calls the above functions. These functions should actually never be called, because without hacks, or through undefined behaviour of your kernel, it is not possible to instantiate a class that doesn't define all pure virtual functions.
 
== Global objects ==
 
{{In_Progress}}
 
TODO: Please unify this information with the newer [[Calling_Global_Constructors]] article.
 
Global objects must have their constructors called before they are used. Usually, they are called by the start-up code (which you just disabled). So, in order to be able to use them, you have to write your own start-up code for them. All objects have a constructor and a destructor. When an executable is loaded into memory and the program jumps straight to the entry point, the constructors of global objects will not have been called. One solution is to do this manually. You could put this code first when your C++ entry point is called:
 
<sourcesyntaxhighlight lang="cpp">
object1.object1();
object2.object2();
object3.object3();
// ...
</syntaxhighlight>
</source>
 
Global or static objects have to be constructed by the environment before they are available to C++. Care should be taken if global/static objects need '''new''' and '''delete''' in their constructors. In this case it is best to construct these objects only after your kernel heap is ready for use (and you have access to dynamic memory allocation). 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 ===
 
Note: This appears to be specific to the Itanium platform. For IA-32/x86/i386 and amd64/x86_64, please check out [[Calling_Global_Constructors]] instead.
 
According to the [http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/baselib---cxa-atexit.html Itanium C++ Application Binary Interface] (which '''g++''' follows and VC++ does not) the function '''__cxa_atexit''' is used to register a destructor that should be called when a shared library needs to be unloaded. It should insert a function pointer with maximum 1 accompanying argument and the handle of the object or shared resource to be destroyed into a table.
 
In the example implementation of '''__cxa_atexit''', the '''__atexit_funcs[ATEXIT_MAX_FUNCS]''' array acts as the table. This is why the '''__cxa_atexit''' function is defined as:
 
<sourcesyntaxhighlight lang="cpp">
int __cxa_atexit(void (*destructor) (void *), void *arg, void *__dso_handle);
</syntaxhighlight>
</source>
 
So that the '''destructor''' function pointer is the handle for a destructor function and '''arg''' is the single argument it may take. Finally, '''__dso_handle''' is a handle for the DSO (Dynamic Shared Object).
Line 54 ⟶ 72:
So summarized, you are required to define two functions and one symbol in order to use global objects in your C++ files:
 
<sourcesyntaxhighlight lang="cpp">
void *__dso_handle;
 
int __cxa_atexit(void (*destructor) (void *), void *arg, void *dso);
void __cxa_finalize(void *f);
</syntaxhighlight>
</source>
 
==== Versions before GCC 3.2 ====
GCC inserts an array of pointers into the object file. Look for the ELF section called '''ctors*'''. Each pointer indicates the constructor of a global / static object. Your Assembly start-up code should call them in turn before passing control to your C++ kernel code.
 
There also is a '''dtors*''' list of destructors. If your kernel returns, the shutdown code should also call them in turn. Remember to destruct your objects in the '''opposite''' order you have constructed them (for the sake of inner dependencies).
 
Additionally, you should see the [[C++ Bare Bones]] tutorial for more information on how to call static constructors.
 
After you have called the objects constructor GCC automatically calls the function
==== Versions after GCC 3.2 ====
The construction of global/static objects is the same as of older versions of GCC. After you have called the objects constructor GCC automatically calls the function
 
<sourcesyntaxhighlight lang="cpp">
int __cxa_atexit(void (*destructor) (void *), void *arg, void *dso);
</syntaxhighlight>
</source>
 
This function should save all three parameters and if successful return zero, on failure non-zero. When your kernel exits you should call '''__cxa_finalize(0)'''. According to the ABI specification, calling this with 0 as the parameter instead of the address of a function (to be called and removed from the list) causes ''all'' destructors in the list to be called and removed from the list.
Line 79 ⟶ 89:
Since you will be calling this function from your Assembly source right after your kernel exits, you could use the following code:
 
<sourcesyntaxhighlight lang="asm">
; This is NASM source, mind you.
sub esp, 4
Line 87 ⟶ 97:
 
add esp, 4
</syntaxhighlight>
</source>
 
The following is tested, working, fully commented source that gives a more detailed explanation than the source previously found here. It also highlights what improvements can be implemented and where they can be inserted. To use it, just include '''icxxabi.h''' in any '''one''' file of your C++ kernel source (preferably the file where your kernel's main statements begin).
 
'''File: icxxabi.h'''
<sourcesyntaxhighlight lang="cpp">
#ifndef _ICXXABI_H
#define _ICXXABI_H
Line 123 ⟶ 133:
 
#endif
</syntaxhighlight>
</source>
 
 
'''File: icxxabi.cpp'''
<sourcesyntaxhighlight lang="cpp">
 
#include "./icxxabi.h"
Line 188 ⟶ 198:
};
 
forwhile ( ; i >= 0; --i)
{
/*
Line 232 ⟶ 242:
};
#endif
</syntaxhighlight>
</source>
 
Additionally, you should see the [[C++ Bare Bones]] tutorial for more information on how to call static constructors.
 
=== Visual C++ ===
Line 246 ⟶ 254:
Below you will find some example code. Simply call '''runInit()''' if you want to initialize any static objects and then call '''runTerm()''' if static object destructors are to be run.
 
<sourcesyntaxhighlight lang="cpp">
typedef void (*_PVFV)(void);
typedef int (*_PIFV)(void);
Line 340 ⟶ 348:
__declspec(allocate(".CRT$XIB")) static _PIFV pinit = onexitinit;
#pragma data_seg()
</syntaxhighlight>
</source>
 
== Local Static Variables (GCC Only) ==
Line 347 ⟶ 355:
''Note that these are only stubs to get the code compiled, and you should implement them yourself. Simply add a mutex-like guard with a test-and-set primitive.''
 
<sourcesyntaxhighlight lang="cpp">
namespace __cxxabiv1
{
Line 374 ⟶ 382:
}
}
</syntaxhighlight>
</source>
 
The actual code emitted by GCC to call a local static variable's constructor looks something like this:
 
<sourcesyntaxhighlight lang="cpp">
static <type> guard;
 
Line 405 ⟶ 413:
}
}
</syntaxhighlight>
</source>
 
== The Operators 'new' and 'delete' ==
Before you can properly use '''new''' and '''delete''', you have to implement some sort of memory management. You also have to implement both operators (including their array counterparts). '''new''' and '''delete''' respectively allocate and delete memory (much like '''malloc''' and '''free''' in C). Take a look at the [[Memory Management]] article if you would like to know more about this subject.
 
GCC provides several standard library functions as built-in, which you most likely do not want in your kernel binary either. Disable them by adding '''-nostdlib''' to '''g++'''. Note that the option '''-ffreestanding''' (usually recommended in kernel tutorials) cannot be used with '''g++'''.
 
Every time 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 your kernel's '''malloc''' and '''free'''. For example:
 
<sourcesyntaxhighlight lang="cpp">
#include <stddef.h>
// size_t depends on your implementation, the easiest would probably be:
// typedef __SIZE_TYPE__ size_t;
 
void *operator new(size_t size)
Line 437 ⟶ 442:
free(p);
}
</syntaxhighlight>
</source>
 
You could also let '''new''' use '''calloc''' (allocate and zero). This way, newly allocated memory will always be zeroed (thus, not contain garbage). The standard '''new''' implementations do however not clear the returned memory.
 
An easy malloc implementation you can port to your OS is [httphttps://wwwgithub.smksoftware.co.za/categorycom/progressblanham/liballoc/ liballoc]. It only requires basic [[Paging]] (that is, store a list of used and free pages, and have a function to find the next free page) to work.
 
=== Placement New ===
In C++ (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'. For example, say you wanted to create an APIC object at address '''0x09FFF0000''', then this snippet of code will use placement new to do the trick:
 
<sourcesyntaxhighlight lang="cpp">
void *apic_address = reinterpret_cast<void *>(0x09FFF0000);
APIC *apic = new (apic_address) APIC;
</syntaxhighlight>
</source>
 
In order to use placement new, you need special overloads of the new and delete operators defined in scope. Fortunately, the required definitions are simple and can be inlined in a header file (the C++ standard puts them in a header called '''new''').
 
<sourcesyntaxhighlight lang="cpp">
inline void *operator new(size_t, void *p) throw() { return p; }
inline void *operator new[](size_t, void *p) throw() { return p; }
inline void operator delete (void *, void *) throw() { };
inline void operator delete[](void *, void *) throw() { };
</syntaxhighlight>
</source>
 
The above implementation can potentially be unsafe for allocating memory since your kernel does not mark the memory that was allocated as being used. Placement new is hardly ever used, and if you wish to read an object from a specified address in memory, it is usually easier to create a pointer to that address.
Line 464 ⟶ 469:
You never call placement delete explicitly (it's only required for certain implementation detail reasons). Instead, you simply invoke your object's destructor explicitly.
 
<sourcesyntaxhighlight lang="cpp">
apic->~APIC();
</syntaxhighlight>
</source>
 
== RTTI (Run-Time Type Information) ==
Line 476 ⟶ 481:
See [[C++ Exception Support]].
 
== Standard Template Library ==
Note that the C++ Standard Library (stdlib) is not the same as the C++ Standard Template Library (STL). The STL was designed in 1994 and largely influenced the C++ Standard Library, but it's not a part of the ISO C++ standard. The C++ Standard Library is part of the C++ ISO specification, however, and is what you're using when you use ''std::vector'', ''std::string'', etc. Be wary of misusing the term STL and, ideally, avoid it completely. Anyone using it almost certainly means the C++ stdlib.
You cannot use STL ([[Standard Template Library]]) functions or classes without porting an STL implementation. Note that C++ classes and templates (e.g. std::vector, std::string) actually aren't part of the C++ language. They are part of a library called the Standard Template Library. A lot of the code depending on STL is OS-dependent, so you must port an STL implementation to your OS if you want to use them.
 
You cannot use stdlib functions or classes without porting a stdlib implementation. A lot of existing code depending on the stdlib is OS-dependent, so you must port an stdlib implementation to your OS if you want to use them.
To gain access to the STL in your OS you can do either of the following:
* Write your own implementation of a few of the required templates classes (std::string, std::list, std::cout, ...).
* Port an STL implementation to your OS (e.g. [[STLport]]).
 
To gain access to the stdlib in your OS you can do either of the following:
A lot of the STL classes require '''new''' and '''delete''' to be implemented in your OS. File access requires your OS to support reading and wrapping. Console functions require your OS to already have working console I/O.
* Write your own implementation of a few of the required class templates (std::string, std::list, std::cout, ...).
* Port a stdlib implementation to your OS (e.g. [[STLport]]).
 
A lot of the stdlib classes require '''new''' and '''delete''' to be implemented in your OS. File access requires your OS to support reading and wrapping. Console functions require your OS to already have working console I/O.
Porting the STL (like porting the [[C Standard Library]]) does not automatically make your OS able to read from and write to the disk or get data straight from the keyboard. These are simply wrappers around your OS' functions, and must be implemented by in your kernel.
 
Porting the C++ stdlib (like porting the [[C_Library|C Standard Library]]) does not automatically make your OS able to read from and write to the disk or get data straight from the keyboard. These are simply wrappers around your OS' functions, and must be implemented by in your kernel.
Note that it is generally not a good idea to port the entire STL to your kernel, although it is reasonable to port a few classes, such as <tt>std::vector</tt> and <tt>std::string</tt> if you wish to. As for your user applications: the more the merrier! :)
 
Note that it is generally not a good idea to port the entire stdlib to your kernel, although it is reasonable to port a few class templates, such as <tt>std::vector</tt> and <tt>std::string</tt> if you wish to. As for your user applications: the more the merrier! :)
Here is a list of a the most commonly used STL implementations:
 
Here is a list of a the most commonly used stdlib implementations:
 
* [http://incubator.apache.org/stdcxx/ STDCXX] (a.k.a Apache C++ Standard Library, formally Rogue Wave C++ Standard Library)
* [https://www.dinkumware.com/cpp.aspx Dinkumware C++ Standard Library]
* [http://msdn2.microsoft.com/en-us/library/cscc687y%28VS.80%29.aspx Microsoft C++ Standard Library] (closed source)
* [http://gcc.gnu.org/libstdc++/ libstdc++] (a.k.a. GNU Standard C++ Library)
* [http://www.stlport.org/ STLport]
* [http://ustl.sourceforge.net/ uSTL]
* [http://libcxx.llvm.org/ libc++] (LLVM C++ Standard library)
 
== Full C++ Runtime Support Using libgcc And libsupc++ ==
{{Main|Libsupcxx#Full C++ Runtime Support Using libgcc And libsupc++}}
The following description is valid for i386, GCC 3.2 and libgcc/libsupc++ compiled for Linux/glibc (you can use the static gcc/supc++ libraries compiled for your Linux for your kernel).
 
If you want Exceptions, RTTI, new and delete altogether, you also could use libgcc and libsupc++. libgcc contains the unwinder (for exceptions), while libsupc++ contains the C++ support. These functions look very complex (gcc_sources/gcc/unwind*, gcc_sources/libstdc++-v3/libsupc++/*), so it might be better to port them instead of trying to write them yourself.
 
To get full C++ support, you only have to do the following:
 
If you want Exceptions, RTTI, new and delete altogether, you should use [[libgcc]] and libsupc++. libgcc contains the unwinder (for exceptions), while libsupc++ contains the C++ support.
* Provide some libc functions (e.g. abort, malloc, free, ...) because libsupc++ needs them. There are even more functions you could support, like pthread_*, but since these are weak symbols, you don't need to define them.
* There's also a strange function dl_iterate_phdrs. You don't need this so let it simply return -1. It's usually used to find exception frames for dynamically linked objects. You could also remove calls to this function from the library.
* To make use of exception handling, you also have to tell libsupc++ where the '''.eh_frame''' section begins. Before you throw any exception: <verbatim>__register_frame(address_of_eh_frames); </verbatim>.
* Terminate the '''.eh_frame''' section with 4 bytes of zeros (somehow). If you forget this, libsupc++ will never find the end of '''.eh_frame''' and generate stupid page faults.
 
You may run into problems with libsupc++, but there are [[GCC_and_Libc++|alternative libraries]].
Please note that you still have to call the constructors/destructors by yourself. Additionally, this sadly enlarges your kernel by approximately 50 kB (or even more). You could also cross-compile [[libsupcxx|libsupc++]] for your kernel.
 
== Optimizations ==
Line 517 ⟶ 518:
== Links ==
=== Wiki ===
* [[C++ Bare Bones|C++ Bare Bones]]
* [[Volatile_(keyword)|Use of the volatile keyword]]
* [[C++ to ASM linkage in GCC|Linking C++ and Assembly (GCC-specific)]]
Retrieved from "https://osdev.wiki/wiki/Special:MobileDiff/975...26456"