Talk:C++ Bare Bones

From OSDev Wiki
Jump to: navigation, search

loader() and startup

The tuorial seems broken - some essential startcode is missing and the C version of loader() does less than the corresponding ASM versions. Besides, you'd probably want to delay initialisation of static classes to the point where you have a working memory manager. - Combuster 06:43, 3 October 2008 (UTC)

Code in .data?

I've been looking at this after a long time, and suddenly one thing strikes me as odd: Why do we place ctors and dtors (which are executable code) in the .data section? Shouldn't this be in the .text section? -- Solar 06:01, 26 October 2010 (UTC)

ctors/dtors are data, an array of function pointers to be precise.
for(unsigned long *constructor(&start_ctors); constructor < &end_ctors; ++constructor) 
   ((void (*) (void)) (*constructor)) ();
This means that with the least privileges it ought to be only readable and not necessarily executable. The .rodata section would technically be more appropriate though - Combuster 14:48, 26 October 2010 (UTC)
Ungh... /facepalm... unbelievable how rusty I've gotten. Of course they're only pointers into .text... moved them into .rodata. -- Solar 10:31, 29 October 2010 (UTC)

borken?

I just had a quick look at the article again, and I found two things that "don't seem right":

  • Shouldn't the C++ version of "loader" be linked extern "C"?
  • Why does the article mention stuff like "if your linker requires adding leading underscore"? Don't we stubbornly recommend the cross-compiler approach to avoid just extactly such fluff in the articles?

-- Solar 08:42, 12 October 2011 (UTC)

Using loader as a C function is especially wrong, since it is later used as the entry point (with ebx and eax holding important information and esp being undefined, the same goes for the assembly equivalents), and declaring that as C linkage does not fix that. I would just split the function into call_static_constructors() and call_static_destructors() and avoid the problem altogether. That is, after fixing the "Note also that you should call the destructors in reverse order!" bug that's contradicting the entire rest of the article.
(And while we're at the tutorial bashing tour, s/main/kmain/ IMO)
In general the tutorial is not self-sufficient while it might better be that way (something I commented on three years ago). And the code looks hacky as an unfortunate consequence.
- Combuster 17:34, 12 October 2011 (UTC)
Gosh... this article is pretty screwed up, is it? I thought we had better than that... -- Solar 07:30, 13 October 2011 (UTC)

In a complete overhaul, I "synced" this article with Bare Bones. It should be self-sufficient now, but I don't have the environment right now to actually test the source.

  1. Somebody please check this "destructors in reverse order".
  2. I feel the calling of constructors and destructors should be done in kmain(). It would make the Multiboot magic number and info structure available to them, and remove the duplicated ASM code from the examples. I might do this edit myself, but not right now.

I hope this improves the article somewhat. -- Solar 08:31, 13 October 2011 (UTC)

Personal tools
Namespaces
Variants
Actions
Navigation
About
Toolbox