Re: The little book about OS development
Posted: Mon Jan 12, 2015 2:13 am
Wouldn't you overwrite stuff in the .bss that way?sortie wrote:Avidanborisov: Stack in the .bss is technically allowed.
OSDev.org
The Place to Start for Operating System Developers
https://f.osdev.org/
The little book about OS development
Page 2 of 2
Re: The little book about OS development
Posted: Mon Jan 12, 2015 2:34 am
Basically, you're claiming that reserving space for the stack in .bss implies the stack will always write outside that reserved space?
Re: The little book about OS development
Posted: Mon Jan 12, 2015 3:41 am
I'm claiming that the way it's done in the the book, the space reserved for the stack and the .bss section coincide.Combuster wrote:Basically, you're claiming that reserving space for the stack in .bss implies the stack will always write outside that reserved space?
Code: Select all
KERNEL_STACK_SIZE equ 4096 ; size of stack in bytes
section .bss
align 4 ; align at 4 bytes
kernel_stack: ; label points to beginning of memory
resb KERNEL_STACK_SIZE ; reserve stack for the kernel
...
mov esp, kernel_stack + KERNEL_STACK_SIZE ; point esp to the start of the
; stack (end of memory area)Re: The little book about OS development
Posted: Mon Jan 12, 2015 3:50 am
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.)With enough stack frames, wouldn't you overwrite stuff in the .bss?
If you think this method of allocating stack space is dangerous, how would you propose to allocate an initial stack?
Re: The little book about OS development
Posted: Mon Jan 12, 2015 4:06 am
The stack grows downwards. So:Avidanborisov wrote: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?
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.
Re: The little book about OS development
Posted: Mon Jan 12, 2015 4:15 am
Oops, just realized now that resb reserves the space for stack. My bad for not really paying attention to the codeiansjack wrote: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.)With enough stack frames, wouldn't you overwrite stuff in the .bss?
If you think this method of allocating stack space is dangerous, how would you propose to allocate an initial stack?
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.
Re: The little book about OS development
Posted: Mon Jan 12, 2015 7:27 am
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.
Re: The little book about OS development
Posted: Mon Jan 12, 2015 3:47 pm
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
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
Re: The little book about OS development
Posted: Wed Jan 14, 2015 4:49 pm
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.
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.
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 area4.2 The Framebuffer
The framebuffer is a hardware device that is capable of displaying a buffer of memory on the screen [26]. The framebuffer has 80 columns and 25 rows, and the row and column indices start at 0 (so rows are labelled 0 - 24).
4.2.1 Writing Text
Writing text to the console via the framebuffer is done with memory-mapped I/O. The starting address of the memory-mapped I/O for the framebuffer is 0x000B8000 [27]
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.
Re: The little book about OS development
Posted: Thu Jan 15, 2015 2:22 am
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.
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.
Re: The little book about OS development
Posted: Thu Jan 15, 2015 2:44 am
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.