Anonymous user
C++: Difference between revisions
no edit summary
| [unchecked revision] | [unchecked revision] |
(Added "Local Static Variables") |
No edit summary |
||
Line 8:
By default, G++ attempts to link in startup code - the stuff usually done before <tt>main()</tt> 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 <tt>-nostartfiles</tt>.
===
TODO: Fill this in.
===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 that support routine.
===
It is a requirement of C++ to provide a backup back up function to call when a virtual function cannot be called.
===
To enable the use of virtual functions in GCC, you simply need the following function in one of your .cpp files. You do not need to place a prototype or anything in any of your headers. The contents of the function itself does not need to print an error message or do anything at all, since most implementations simply do nothing if the pure virtual function call cannot be made.
The following code applies to GCC:
<pre>
extern "C" void __cxa_pure_virtual()
Line 44 ⟶ 30:
</pre>
The following code applies to Visual C++:
<pre>
int __cdecl _purecall()
Line 52 ⟶ 38:
</pre>
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. But nonetheless you have to define
===Global objects===
Global objects must have their constructors called before they are used... and they would usually be called by the startup code you just disabled. So, stay away from global objects until you have set up your own kernel startup code.
====Why?====
All objects in have constructor and deconstructor code. When an executable code is loaded into memory, and the program jumps straight into main, the constructor code for each global object has not be run. You could do this manually, by calling in the top of <tt>main()</tt>:
<pre>
object1.object1();
object2.object2();
object3.object3();
// etc
</pre>
====Enabling global objects====
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 <tt>__cxa_atexit</tt>, because you don't have to use a static and fixed-size structure.
GCC (version < 3.2)
Line 63 ⟶ 61:
There also is a "dtors*" list of destructors; if your kernel returns, the exit / cleanup code should also call them in turn. Remember to destruct your objects in the opposite order you have constructed them.
=====GCC >= 3.2=====
: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 <tt>-fabi-version</tt>. I do get a dtors section.
Line 115 ⟶ 113:
</pre>
=====Visual C=====
Running constructors and destructors is covered in MSDN help and in the C runtime library sources. See <tt>#pragma init_seg</tt> on MSDN for some more information.
Line 221 ⟶ 219:
</pre>
===Local static variables (GCC only)===
When you declare local static variable, at least GCC compiler, puts a guard around variable's constructor call. This ensures that only one thread can call constructor at the same time to initialize it.
====Why?====
TODO: Fill this in.
====Enabling local static variables====
Note, that these are only stubs to get the code compiled, and you should implement them yourself. Simply add a mutex like guard with test and set primitive.
Line 277 ⟶ 278:
}
</pre>
===new and delete===
Before you can use new and delete, you have to implement some memory management, and the operator <tt>new()</tt> and operator <tt>delete()</tt> functions (including their array counterparts).
====Why?====
<tt>new()</tt> and <tt>delete()</tt> allocate memory and free memory, respectively. For your kernel to allocate memory, it must somehow store what part of memory is used and what part of memory is free to be divided and allocated.
====Enabling new and delete====
Every time you call one of the operators <tt>new()</tt>, <tt>new[]()</tt>, <tt>delete()</tt>, or <tt>delete[]()</tt>, the compiler inserts a call to them. The most simple implementation would be to map them to <tt>kmalloc()</tt> / <tt>kfree()</tt>: (or malloc() and free() depending on your implementation)
<pre>
Line 308 ⟶ 317:
</pre>
An easy malloc implementation you can port to your OS is [[liballoc]]. It only requires basic page management (that is, store a list of used and free pages, and have a function to find the next free page) to work.
====Other things you can try: Allocate and initialise memory====
New can use <tt>kcalloc</tt> (allocate and zero) instead of <tt>kalloc</tt> to allocate memory and intialise it (that is, fill it with '\0's) otherwise the variables will be filled with garbage which you will then need to clear manually. (The standard implementations of <tt>operator new()</tt> and <tt>operator new[]()</tt> do not initialize the memory returned.)
====Other things you can try: Placement new====
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 <tt>0x09fff0000</tt>. This snippet of code will use placement new to do the trick:
<pre>
void* apic_address = reinterpret_cast<void*>(0x09fff0000);
APIC* apic = new (apic_address) APIC;
</pre>
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>).
<pre>
inline void* operator new(uint_t, void* p) throw() { return p; }
inline void* operator new[](uint_t, void* p) throw() { return p; }
inline void operator delete (void*, void*) throw() { };
inline void operator delete[](void*, void*) throw() { };
</pre>
The above implementation can be potentially 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. [[liballoc]] does not support placement new.
You never call placement delete explicitly (it's only required for certain implementation detail reasons). Instead, you simply invoke your object's destructor explicitly.
<pre>
apic->~APIC();
</pre>
===Builtins===
GCC provides several standard library functions as builtins, which you most likely do not want in your kernel binary either. Disable them with -nostdlib
Note: the option <tt>-ffreestanding</tt>, usually recommended in kernel tutorials, cannot be used with G++.
====Why?====
TODO: Fill this in.
===Run-time type information===
Run-time type information is used for <tt>typeid</tt> and <tt>dynamic_cast</tt>, and requires run-time support as well. Disable it with <tt>-fno-rtti</tt>.
Note that RTTI is required for some C++ features. If you disable it, you won't be able to use <tt>typeid</tt> or <tt>dynamic_cast</tt>. Virtual functions should work without RTTI, though.
====Why?====
TODO: Fill this in.
===Exceptions===
Another feature that requires run-time support. Disable them with <tt>-fno-exceptions</tt>.
====Why?====
TODO: Fill this in.
====Enabling exceptions====
TODO: Fill this in, rather than just dump links.
* http://www.codesourcery.com/cxx-abi/abi-eh.html (sounds like being Itanium specific, but that's actually the base for the common C++ ABI)
* http://www.codeproject.com/cpp/exceptionhandler.asp (explaining the stuff, but for VC++. Note that, on x86, VC++ and most other PC compilers use a [[Stack#Unwinding the stack|stack-based unwinding]] and handling mechanism known as SEH, common to OS/2, Windows and Windows NT and described in detail in a famous MSJ article, http://www.microsoft.com/msj/0197/Exception/Exception.aspx. GCC and most other UNIX compilers, instead, use the same table-based mechanism that is the rule on RISC architectures on x86 too. Also note that any use of stack-based SEH may or may not be covered by USPTO patent #5,628,016, held by Borland International, Inc. SEH on RISC architectures is table-based, thus unaffected by the patent)
Line 348 ⟶ 379:
Note that there is a standard header <exception>, declaring several support functions.
===Standard Template Library===
You cannot use [[Standard Template Library]] (or STL for shor) functions and classes without porting a Standard Template Library implementation. These include <tt>std::vector</tt>, <tt>std::list</tt>, <tt>std::cin</tt>, <tt>std::cout</tt>, etc.
====Why?====
C++ classes and templates such as <tt>std::vector</tt>, <tt>std::list</tt>, <tt>std::cout</tt>, <tt>std::string</t>, to name a few, are not actually 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.
====Porting a Standard Template Library====
TODO: Create an article on porting STLport.
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, etc).
- Port an STL implementation to your OS (e.g. [[STLport]]).
A lot of the STD classes require <tt>new</tt> and <tt>delete</tt> implemented in your OS. File access requires your OS to support reading and wrapping. Console functions require your OS to already have working console input/output.
Porting STL, the same with the [[C Standard Library]], do not automatically make your OS to be able to read from and write to the disk, or to get data straight from the keyboard. These are simply wrappers around your OS's functions, and must be implemented by you.
Note that it is generally not a good idea to port the entire OS to your kernel, although it is reasonable to port a few classes, such as <tt>std::list</tt> and <tt>std::string</tt> if you wish to. As for your user applications; the more the merrier! :)
==Full C++ Runtime support with libgcc and libsupc++==
The following description is true 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).
Line 367 ⟶ 419:
You could also cross compile [[libsupcxx|libsupc++]] for your kernel.
== Things you should know about optimizations ==
| |||