OSDev.org

It might be needed in kernel code (C, not asm) which would require inline assembly which AFAIK is bad due to the compiler optimisation. To be honest, I have no idea why it might be needed in the future but I am trying to completely separate the main part of the kernel from the bootloader and boilerplate in terms of development. Anyways, I don't think the pressing issue is optimization right now, but in the future I will probably reduce those to simple instructions.

Anyways, I don't think the pressing issue is optimization right now, but in the future I will probably reduce those to simple instructions.

Just do it already.

ThisMayWork wrote:I think you are correct, the first item of the stack should be a return address, then the parameters in reverse order, but that still does not explain why it ends up being 0x0.

The 0 comes from uninitialized memory. Your stack contains 1 item, and the C function expects 2, so it reads past the top of the stack.

Octocontrabass wrote:

ThisMayWork wrote:I think you are correct, the first item of the stack should be a return address, then the parameters in reverse order, but that still does not explain why it ends up being 0x0.

The 0 comes from uninitialized memory. Your stack contains 1 item, and the C function expects 2, so it reads past the top of the stack.

So since kernel_entry() is never going to return all it takes to fix this is push a random value on the stack? Give me a second to try this
UPDATE: I added "push 0x0" before I push the multiboot info address but sadly nothing changed... I must have an incorrect understanding of the way parameters work.

ThisMayWork wrote:I added "push 0x0" before I push the multiboot info address

The return address normally gets pushed to the stack by the "call" instruction. Does the "call" instruction go before or after the code that pushes parameters to the stack?

ThisMayWork wrote:I must have an incorrect understanding of the way parameters work.

I agree.

First the parameters are pushed and then the function is called... But the stack is read in reverse so it should be working correctly.

ThisMayWork wrote:First the parameters are pushed and then the function is called...

When does the return address get pushed to the stack?

ThisMayWork wrote:But the stack is read in reverse so it should be working correctly.

What do you mean "in reverse"?

First the arguments are pushed then the return address. They are retrieved in reverse order (LIFO). That means that they end up in the correct place in my "custom" stack frame setup. Or at least I think so

ThisMayWork wrote:I added "push 0x0" before I push the multiboot info address

ThisMayWork wrote:First the arguments are pushed then the return address.

I know you don't want me to just give you the answer, but you're making it awfully tempting...

I still can't spot it... In order for kernel_entry() to behave correctly the stack should look like this:
-Return Address
-(Argument 2, if it existed)
-Multiboot Info Address

And it does look like this...

I always tend to forget the intel stack grows downwards... Still, this should not affect the order of the elements.
EBP --> (An element)
Then comes the push instruction and the stack looks like this:
EBP --> (An element)
ESP --> (MB Info)
Then the call
EBP --> (An element)
(MB Info)
ESP --> (Return Address)
Then the kernel_entry will receive first the return address and then the first argument. I am still confused on this. Isn't my diagram of the stack correct?

ThisMayWork wrote:I always tend to forget the intel stack grows downwards... Still, this should not affect the order of the elements.
EBP --> (An element)
Then comes the push instruction and the stack looks like this:
EBP --> (An element)
ESP --> (MB Info)
Then the call
EBP --> (An element)
(MB Info)
ESP --> (Return Address)
Then the kernel_entry will receive first the return address and then the first argument. I am still confused on this. Isn't my diagram of the stack correct?

yes, it is correct...

think it through, what is going to happen as you make each push to the stack -- does that match this diagram?

At first, ebp and esp point at the same address. Then MB Info is pushed, so it's size is subtracted from esp. Then the call happens and esp is subtracted again in order to hold the return address. That should match the diagram... Gah, I'm even more confused

ThisMayWork wrote:Then the call happens

Where?