OSDev.org

iansjack wrote:Are you serious? You alter the stack pointer and then wonder why variables and return don't work.

The best advice I can give is for you to put OS development on hold, find a good book or tutorial on assembler programming, and learn how the computer works at that level. You could usefully experiment with simple user programs. Pay particular attention to how variables are stored - both global and local - how function calls and interrupts work, and the roles of the esp and who registers. You'll also need to familiarise yourself with the way that parameters are passed to functions ( I should really say ways, as there's more than one possible way of doing this).

An understanding of the processor is essential to OS development.

mrjbom wrote:

iansjack wrote:Are you serious? You alter the stack pointer and then wonder why variables and return don't work.

The best advice I can give is for you to put OS development on hold, find a good book or tutorial on assembler programming, and learn how the computer works at that level. You could usefully experiment with simple user programs. Pay particular attention to how variables are stored - both global and local - how function calls and interrupts work, and the roles of the esp and who registers. You'll also need to familiarise yourself with the way that parameters are passed to functions ( I should really say ways, as there's more than one possible way of doing this).

An understanding of the processor is essential to OS development.

I was guided by this wiki article.
It's clearly written "In protected mode you set up the stack by just moving a new pointer value into the ESP register"

What did I get wrong?

mrjbom wrote:I will definitely start reading some book about the 8086 processor, this is really my weakness.
But I still don't understand why wiki suggests changing the esp.

• When a CALL instruction is executed, the CPU pushes the return address to the stack
• When RET instruction reached, it pops the value from the top of the stack and continues execution at that address

• in the function prologue, as the first thing to do, the EBP register is pushed on the stack, and then it is set to the current ESP. Now you have two words on the stack: the return address and the previous EBP. Then on function return,
• in the function epilogue before the RET instruction, this previous EBP popped.

a.c:
int dprintf()
{
}

int main()
{
    dprintf();
}

$ gcc a.c -o a
$ objdump -d a
...
0000000000001119 <dprintf>:
    1119:	55                   	push   %rbp             <- function prologue
    111a:	48 89 e5             	mov    %rsp,%rbp

    111d:	90                   	nop                     <- function body

    111e:	5d                   	pop    %rbp             <- function epilogue
    111f:	c3                   	retq                    <- "POP InstPointer"

0000000000001120 <main>:
    1120:	55                   	push   %rbp             <- function prologue
    1121:	48 89 e5             	mov    %rsp,%rbp

    1124:	b8 00 00 00 00       	mov    $0x0,%eax        <- function body
    1129:	e8 eb ff ff ff       	callq  1119 <dprintf>   <- "PUSH InstPointer" + "JMP"
    112e:	b8 00 00 00 00       	mov    $0x0,%eax

    1133:	5d                   	pop    %rbp             <- function epilogue
    1134:	c3                   	retq   
...

bzt wrote:

mrjbom wrote:I will definitely start reading some book about the 8086 processor, this is really my weakness.
But I still don't understand why wiki suggests changing the esp.

Yes, you should. Here are the basics in a nutshell with the relevant search phrases in bold.

Stack is list of words, growing downwards, the top pointed by the ESP register. You can push values into it, and pop the value on the top.

The CPU implicitly uses the stack.

• When a CALL instruction is executed, the CPU pushes the return address to the stack
• When RET instruction reached, it pops the value from the top of the stack and continues execution at that address

So simply by calling "dprintf", your code changed the stack (and decreased ESP).

Function local variables are also stored on the stack. To reliably address those variables, something called Stack Frame is used, which has two parts:

• in the function prologue, as the first thing to do, the EBP register is pushed on the stack, and then it is set to the current ESP. Now you have two words on the stack: the return address and the previous EBP. Then on function return,
• in the function epilogue before the RET instruction, this previous EBP popped.

This code is added automatically by your compiler, which then addresses all function local variables relative to EBP (so it does not use ESP, which is a moving target).

Example

Code: Select all

a.c:
int dprintf()
{
}

int main()
{
    dprintf();
}

Compile and disassemble (sorry, I couldn't find a 32 bit compiler, I'm using 64 bit, so there's RSP, RBP, CALLQ, RETQ instead of ESP, EBP, CALL, RET, but the concept is the same):

Code: Select all

$ gcc a.c -o a
$ objdump -d a
...
0000000000001119 <dprintf>:
    1119:	55                   	push   %rbp             <- function prologue
    111a:	48 89 e5             	mov    %rsp,%rbp

    111d:	90                   	nop                     <- function body

    111e:	5d                   	pop    %rbp             <- function epilogue
    111f:	c3                   	retq                    <- "POP InstPointer"

0000000000001120 <main>:
    1120:	55                   	push   %rbp             <- function prologue
    1121:	48 89 e5             	mov    %rsp,%rbp

    1124:	b8 00 00 00 00       	mov    $0x0,%eax        <- function body
    1129:	e8 eb ff ff ff       	callq  1119 <dprintf>   <- "PUSH InstPointer" + "JMP"
    112e:	b8 00 00 00 00       	mov    $0x0,%eax

    1133:	5d                   	pop    %rbp             <- function epilogue
    1134:	c3                   	retq   
...

As you can see, both "main()" and "dprintf()" has extra instructions to handle the stack frame, and those are push/pop which alter the stack.

This means you can change the stack (actually this is essential in context switching), but you must do that carefully, knowing exactly what's in the stack, so that the code that pushed values onto the old stack can pop the same many values from the new stack.

Cheers,
bzt

mrjbom wrote: However, the problem is that the esp changes depending on where I read it. For example, if I read the esp value in kmain, the value is always the same, and if in a function that is called from kmain(), it is different.

mrjbom wrote: I expected the esp to never change from the moment it was installed.

iansjack wrote:You really, really need to go back to basics and learn about the x86 processors and assembly language before you go any further. You are knitting together a mish-mash of advice from here and code from the Internet without the knowledge to understand it.

You need to understand the basics of computers before tackling a project like an OS. And, IMO, people are doing you no favours by providing you with snippets of knowledge.

mrjbom wrote:

iansjack wrote:You really, really need to go back to basics and learn about the x86 processors and assembly language before you go any further. You are knitting together a mish-mash of advice from here and code from the Internet without the knowledge to understand it.

You need to understand the basics of computers before tackling a project like an OS. And, IMO, people are doing you no favours by providing you with snippets of knowledge.

I read the literature about it.

That's why I'm asking how the stack works here.

PeterX wrote:

mrjbom wrote:

iansjack wrote:You really, really need to go back to basics and learn about the x86 processors and assembly language before you go any further. You are knitting together a mish-mash of advice from here and code from the Internet without the knowledge to understand it.

You need to understand the basics of computers before tackling a project like an OS. And, IMO, people are doing you no favours by providing you with snippets of knowledge.

I read the literature about it.

That's why I'm asking how the stack works here.

Well, then you have read the wrong literature! If you would have read a x86 Assembler book you would know how the stack works!

I think there are good gratis tutorials about x86 assembler on the net. If you really don't know the basics like stack etc. than iansjack is right and tips (like from me) won't help you at all.

Use your favorite search engine and osdev.org's wiki to learn assembler. Then (and only then) learn protected mode. Then come back.

I additionally would advice you to stick to application programming before you go for OS developing. I see from your questions that you already have some technical knowledge. But this seems to lead you to the wrong impression you were prepared for OS dev.

As always: This is just an advice to help you. I have not the right or will, to push you away from OS dev if you want to.

Happy hacking
Peter