2

I am reading the multiboot specification of the grub in its manual.While I am reading this manual, I found an one specification.This specification mention as like "When the boot loader invokes the 32-bit operating system,operating system image must create its own stack as soon as it needs one.".I don't understand this specification,why OS needs to create the stack.

Min Thuta Shein
  • 33
  • 8
  • 1
    The multiboot spec is saying that you shouldn't rely on there being an appropriate stack pointer value in _ESP_. As long as you don't need to use any stack operations (eg: push, pop call etc)you are fine. Since many mulitboot bootstrap programs will end up doing a _CALL_ instruction (typical if you try calling into a _C_ function) then an invalid stack pointer could cause a fault (not likely unless you enabled paging with identity mapping), but could get clobbered if your program inadvertently over wrote the stack while running. Setting up your own temporary stack means you know where it is. – Michael Petch Sep 13 '16 at 17:15
  • 1
    You can create a temporary stack in the _BSS_ segment as it won't take up space in your code. You then set _ESP_ to the end of that memory area you allocate (since the stack grows downward). This is usually done with the assembler code in your multiboot object and is done before the first push/pop/call (or any other instruction that requires pushing something on the stack) instruction. – Michael Petch Sep 13 '16 at 17:19
  • 1
    Since it looks like you might be doing OS Development, this kind of question can be asked in this [#OSDev IRC chat](https://kiwiirc.com/client/irc.freenode.net/#osdev) . Many people in there have a lot of experience with Operating System development including multiboot questions. Many people there are working on their own tow operating systems, and some have been at it for many years. – Michael Petch Sep 13 '16 at 17:24
  • Thanks.Now,I get an understanding,what about this specification want to say,from your answers. – Min Thuta Shein Sep 13 '16 at 17:38

1 Answers1

3

It's a specification. Specifications typically make "guarantees" as to what state the cooperating component can depend on, and what it may not depend on.

In this case, the specification is saying that the loaded OS may not assume that the stack pointer's contents reference an area of memory usable as a stack. That doesn't mean that the stack pointer doesn't actually point to an area of memory usable as a stack (it might). It means you had better not rely on it, as a future version of the loader is free to use the register for something else. Your OS would then likely crash when loaded by that later version.

That being said, there are likely other reasons as well. For example, in x86, the stack pointer (RSP/ESP/SP) is interpreted relative to the contents of the SS segment register. When changing modes -- say, real mode to protected mode -- the structure and interpretation of the segment registers changes; hence, a stack pointer value that makes sense in one mode may point to a completely different area of memory in the other (or even to no valid area of memory).

Gil Hamilton
  • 11,973
  • 28
  • 51
  • 2
    With the multiboot spec you can probably assume they are in 32-bit protected mode already since that is one thing a multiboot compliant bootloader will do for you. That is assuming you didn't manually jump back into real mode – Michael Petch Sep 13 '16 at 17:09