I guess one can easily test whether gcc produces this "garbage" by having a look at the contents of the ctor/dtor lists. No matter whether it is necessary for one kernel or not for another - if it is present, one must be careful not to call something that is not a constructor. According to the gcc docs,
gcc wrote:
Each list always begins with an ignored function pointer (which may hold 0, −1, or a count of the function pointers after it, depending on the environment). This is followed by a series of zero or more function pointers to constructors (or destructors), followed by a function pointer containing zero.
I don't use global C++ objects in my kernel, so it would take me some time to write some simple test code, but I remember that I once worked on an OS named
Trion, which actually relied on the first entry of the ctor/dtor list being the number of ctors/dtors, as you can see from this code:
Code:
// Walk and call the constructors in the ctor_list
void ExecuteConstructors(void)
{
// Get a copy of the contructor list
void (**constructor)(void) = &ctorStart;
// The constructor list first contains an integer
// containing the number of ctors, and then the
// actual list begins...
int total = *(int *)constructor;
constructor++ ;
while(total--)
{
(*constructor)() ;
constructor++ ;
}
}
void ExecuteDestructors(void)
{
void (**deconstructor)(void) = &dtorStart;
int total = *(int *)deconstructor ;
deconstructor++ ;
while(total--)
{
(*deconstructor)() ;
deconstructor++ ;
}
}
So it seems that there is indeed a bug in the barebones tutorial. However, I wonder why nobody has noticed it yet... Calling some invalid address right at the beginning of any kernel code should almost inevitably lead to a triple fault.
Login
Register
FAQ
Search
