OSDev.org

Wouldn't you overwrite stuff in the .bss that way?

Basically, you're claiming that reserving space for the stack in .bss implies the stack will always write outside that reserved space?

I'm claiming that the way it's done in the the book, the space reserved for the stack and the .bss section coincide.


The space reserved for the stack starts right at the beginning of the .bss section. With enough stack frames, wouldn't you overwrite stuff in the .bss?

Since the stack is the first item in the .bss section, how could it possibly overwrite other variables stored there? (It could, but only if you tried to pop more items from it than had been pushed.)

If you think this method of allocating stack space is dangerous, how would you propose to allocate an initial stack?

The stack grows downwards. So:
1) It would more likely write into .data when full
2) You're assuming the stack overflow to prove the stack overflow, which is a circular argument.
3) A stack overflow would be the actual bug, not the placement of the stack in memory. You can put it anywhere and with enough pushes or pops, it will reach into areas it shouldn't.

Oops, just realized now that resb reserves the space for stack. My bad for not really paying attention to the code
My thought was that the stack isn't really the first item in the .bss section, that we just make esp point to <.bss + 4096>. This way we could obviously overwrite stuff in the .bss section.

Either way, I believe the way it's done in Bare Bones (with a separate .stack section) is nicer.

The .stack section in Bare Bones is combined above other static data by the linker. Arguably this is more dangerous, as you pointed out, because an overflowing stack will - in this case - overwrite other static data. In the end you can use paging to totally isolate the stack so that the result of an overflowing stack is a page exception. The OS can then handle this in whatever manner it deems appropriate - at least this way you get a well-defined exception rather than mysteriously corrupted data.

Everyone, again, thanks for all the great feedback (both criticism and encouragement), it is deeply appreciated! I will try to follow this thread and file issues on github based on your comments and feedback (and then hopefully fix those issues).

Combuster, sortie: Thanks for answering my question about using a cross-compiler. I agree that the text desperately needs a paragraph about using a cross-compiler.

EDIT: spelling

I'll start with the good stuff.

I like the idea behind this project, and hosting the stuff you learned along the way as a small book/tutorial on
GitHub pages is cool. It's well organized, has clear and informative illustrations.

Unfortunately, I get the feeling that you rushed writing the text before fully understanding the concepts yourself.

Stuff like the quote below clearly shows just how much of the the terms and concepts that you have mixed up.



You basically just said that a memory mapped I/O area is a piece of hardware, that the same memory area
has columns and rows. Yes that's right. RAM has rows and columns, apparently.

You further explain how the console (how you define a console is anyones guess) is written to via the
memory mapped I/O area with the help of memory mapped I/O.

The VGA-chip or whatever do-all-legacy-stuff-chip that simulate the VGA's capabilities these days, is the
actual hardware responsible for providing the text based output mode that the computer boots into.

The framebuffer in this case is just another name for the memory mapped I/O area, not a piece of hardware.
The specific textmode of the VGA that provides space for 80 columns and 25 rows is called mode 0x03.

As a native English speaker and programmer, I don't find that particular section on the framebuffer ambiguous nor wrong at all.

Sure it could be phrased in a myriad of different ways, each way lending weight to some aspect that some other programmer feels most important. But for text for beginners I don't see the harm or inaccuracies at all.

Text mode doesn't qualify for being/having a framebuffer at all. It's rendered as tiles and lacks a memory location for each individual pixel on the screen.