OSDev.org

Hello.
  I want to boot C++ kernel linked into elf. I'd like to know what I need to do before I run the kernel, to run properly. What about global constructors, and such stuff?
  Thanks for any responses.

Hi!

I am trying to make my own C++ based OS and has written a short manual on how to
compile a binary kernel (http://copsy.sourceforge.net). It's not complete.
About constructors, the compiler takes care about that.
You could use GRUB to load ELF kernels. GRUB does the jump into p-mode for you.
There are more information on GRUB some pages back on this board.
One thing that you could do, is using linker scripts, in which you can specify exactly how to load the ELF kernel ett linking time. Check the info pages in DJGPP for that.

Myself I am a little stucked with GRUB, it seems like I need linux for that.
Note that I never have loaded an ELF kernel before with GRUB, but I think this can give you a clue how to do it.

// Krillzip good luck!!

Uhm... I think the original poster was looking for information on how to write the new and delete functions, as well as how to handle virtual functions and other C++ things (ie, the actual difficult part of writing kernels in C++).

I have no knowledge on this, so perhaps you can confirm an educated guess... I'm assuming new and delete are defined as actual "extern C" fuctions as follows:

void *new(long size);
void delete(void *addr);

Just like malloc and free... ?

And what of virtual functions?  Will the compiler handle that itself, or is there another compiler dependant process involved (such as look-up tables/functions which must be defined)?

These, I think, are the questions the original poster was inquiring about (and I'm kinda curious myself (although I'm writing my kernel in C)).

Oh, and just one little point:
When you define a class as global, there is no extra code added to the binary to initialize and locate static memory, as you say in your tutorial!

The class simply "exists" withen the binary, whereas if it were local, the class specific data would be stored on the stack, therefore not taking up space in the binary.

Just a little thing... I know... but...

Cheers,
Jeff

That's quite easy:

write .cpp file with:

extern "C" void * malloc(unsigned long);
extern "C" void free(void *);

void * operator new(unsigned long sz)
{
return malloc(sz);
}

void * operator new[](unsigned long sz)
{
return malloc(sz);
}

void operator delete(void * _p)
{
free(_p);
}

void operator delete[](void * _p)
{
free(_p);
}

// Also use one of those

extern "C" void _pure_virtual(void) /* For DJGPP */
{
printf("Pure virtual function call\n");
}

extern "C" void __pure_virtual(void) /* For Linux */
{
printf("Pure virtual function call\n");
}

extern "C" void _cxa_pure_virtual(void) /* For GCC 3.0 under DJGPP */
{
printf("Pure virtual function call\n");
}

extern "C" void __cxa_pure_virtual(void) /* For GCC 3.0 under Linux ???? */
{
printf("Pure virtual function call\n");
}

Now you have only new/delete.