strange stack fault

[bluecode]

hi,

I discovered a strange problem. I'm currently implementing stack-based task-switching. I've got a stack from the highest possible address (0x100000000) downwards. What I do is set esp to 0x00000000 then push eflags, cs and eip in order to make a task-switch (no priviledge change!). Pushing these values onto the stack does not trigger the stack fault. Only when doing an iret(d), the stack fault occures. Bochs error message is: "iret: CS not within stack limits". I also tried it on my real pc and it doesn't work either. Then I tried to set esp to 0xFFFFFFF0 and it works - no stack fault, just works . When setting esp to 0xFFFFFFFC it doesn't work either.
Isn't that strange ???

[Freanan]

Maybe i am wrong but as far as i know the highest possible adress is 0xffffffff, ie your_value-1
That still does not explain, why pushing the values worked...

[bluecode]

I set esp to 0, so when you push a dword, the processor subtracts 4, get an address of 0xFFFFFFFC and writes the value to that address, so there should be no problem, or?

[proxy]

the subtraction happens before, not after the data is written.

proxy

[AR]

You are using paging? The only explanation that currently comes to mind is that you are writing in physical memory and there is a memory mapped device that doesn't support reading that register so it faults causing a stack fault exception.

[Brendan]

Hi,

You are using paging? The only explanation that currently comes to mind is that you are writing in physical memory and there is a memory mapped device that doesn't support reading that register so it faults causing a stack fault exception.

On most/modern computers, the BIOS itself (i.e. the full BIOS rather than just the part mapped below 1 MB) is at the top of the physical address space, so the stack would be in ROM if paging wasn't enabled. In this case I'd expect a general protection fault during the IRET, caused by CS.

A stack fault is typically caused by exceeding the stack segment limit.

I have a feeling that it'd be possible to pop dwords off the stack, let it wrap from 0xFFFFFFFC to 0x00000000 and then keep popping more from the stack, but instructions that cause more than 4 bytes to be taken from the stack would cause problems (e.g. doing "POPAD" or "IRETD" when ESP = 0xFFFFFFFC). I'm not sure though (I'd need to test it).

Despite all of this, the fact that the same problem occurs when ESP starts at 0xFFFFFFFC and no wrapping is meant to be involved, makes me think the problem is something to do with broken task switching code, messed up SS base or limit, or something along those lines. To be honest broken task switching code would be my first assumption...


Cheers,

Brendan

[bluecode]

hi,

thanks for all your replies, but it was false alert . Paging code was broken (didn't clear the page directory correctly)