Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I want to change the stack so I can store a list of free 4k pages. I need two stacks, one for pages with addresses less than 16Mb and one for more than 16mb. I wrote a short assembly subroutine(NASM Syntax) which I call from C:
[global switchstk]
switchstk:
pop eax
mov esp,eax
ret
When I run this in Bochs and a real computer, my exception handler reports invalid opcode! I look at the bochs screen and it says unknown opcode and then op=0x53. Maybe it is because my kernel grew from 8kb to 12 kb( do I have to update my linker script? IF so, how?). WHen I take out the ret statement and use jmp $ there is no exception but I can't use that because my computer will hang. Is it because to return back, the computer needs to pop cs and ip off the stack and it can't because the stack is different and it loads garbage into cs and ip then jmps to it? Or is this just some weird thing that has something to do with NASM not creating a correct file.
If I am switching stacks wrong could someone please tell me the correct way?
ps. :sorry if this is too long I am just frustrated
This is just plain hazardous. When you change esp, then ret, the processor looks on the stack for the return address, which is no longer valid because you just changed the stack. Don't play with the stack pointer unless you're sure you're putting it in a valid place.
I would advise you not to bother changing the stack pointer for a page stack. Just simulate one. Keep a pointer variable for your page stack pointer, and increment, decrement, load, and store as necessary for it to act like a stack.
Okay thanks. I already did start using pointers before I posted this but I was wondering if my error was because the size of my kernel went up. I thought maybe something was wrong with my linker script.
What happened here is that when it executed the "ret" instruction there wasn't any actual valid EIP in the stack. So the processor "happily" jumped into limbo and executed some things you probably don't want it to.