The G (granularity) flag is used to tell the CPU if the limit has byte granularity (e.g. "limit = 0xFFFFF" means 1 MiB limit) or if the limit has page granularity (e.g. "limit = 0xFFFFF" means 1048575 pages or 4 GiB).
Basically the G (granularity) flag is clear so the segment limit is 1 MiB. For "mov esp, 0xA0010" your stack will be below the 1 MiB limit, so you'd be able to use the stack without general protection faults.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
If the granularity flag is clear, the segment size can range from 1 byte to 1 MByte, in byte increments.
If the granularity flag is set, the segment size can range from 4 KBytes to 4 GBytes, in 4-KByte increments.
But I am still wondering, Why occur the error?, if the range from A0010 to 0xFFFFF is < 1MB
okaox wrote:PD: with [mov esp, 0xA0010] have no problem, more than this I get limit error ...
okaox wrote:But I am still wondering, Why occur the error?, if the range from A0010 to 0xFFFFF is < 1MB
Are you *sure* it's a problem with the segment limit?
For example, is it possible that you're trying to put your stack in the middle of video display memory or ROM, and the error is caused by the CPU pushing stuff onto the stack (e.g. the return address for "call" instructions) and popping off something different later (e.g. some bytes of ROM that causes RET to return to a dodgy address and makes the CPU execute unknown instructions, that leads to lots of new and exciting ways to crash)?
Correct me if I'm wrong, but shouldn't there be five f's there, not four?
In the lowest 16 bits of the limit there's only four F's. In the next 4 bits of the limit (e.g. in the "Limit[16..19]" field) there's another F...
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Brendan wrote:Are you *sure* it's a problem with the segment limit?
For example, is it possible that you're trying to put your stack in the middle of video display memory or ROM, and the error is caused by the CPU pushing stuff onto the stack (e.g. the return address for "call" instructions) and popping off something different later (e.g. some bytes of ROM that causes RET to return to a dodgy address and makes the CPU execute unknown instructions, that leads to lots of new and exciting ways to crash)?
I'm pretty confident that Brendan is right. With a base of zero, 0xfffff - 4 is in the middle of ROM. By the way, you'd better align the stack to 0xffffc.
Your stack pointer is fine, the return value on the stack is not. It's one of two things:
* You are deliberately trying to RET to code outside of the 0xFFFFF limit. In this case, set the granularity bit(s) in your GDT.
* You are intending to run code within the correct limits, but your stack is corrupted. What is the last value on your stack? Is it what you expect it to be?