OSDev.org

I've quite strange problem with Bochs. I'm trying to switch to v8086 task, but I'm getting "prefetch: RIP > CS.limit". In log file I have this kind of information so my guess is that task switching started. Almost all registers was loaded from TSS except EIP. I've changed it value tss.eip = 0 but in log file EIP = 0x10000 (my code segment is without granularity with max size = 1MB maybe it has some meaning). Then I've changed tss.eip = 1 in log I've EIP = 0xFFFF. After some tryies I've noticed that when I write odd numbers (1,3,5...) I'm getting in log EIP = 0xFFFF and when I write even numbers (0,2,4...) I'm getting in EIP = 0x10000. After putting number above 0x10000 Bochs says: "call_protected: EIP not within CS limits". I think that my tss structure is good since normal tasks (not v8086), are doing fine. Anybody knows what's going on?

Isn't RIP a 64-bit register for long mode?

Or does it mean RIP as in dead?

Make sure your TSS structure declaration matches the intel manuals, v8086 mode may be more picky than 'normal' mode. Also try to get a dump of your GDT and/or LDT (whichever has the v8086 segments in it). You may have those misconfigured.

No clue.. but RIP they mean return intruction pointer not rest in peace

RIP > CS.limit == return pointer > CS.selector.limit

Basically you tried to return to somewhere that wasn't code, this'll usually be due to a messed up stack or somesuch.

Ryu wrote: No clue.. but RIP they mean return intruction pointer not rest in peace

RIP > CS.limit == return pointer > CS.selector.limit

RIP is the extended EIP, which was the extended IP, which was the instruction pointer. You tried to load (not return) an instruction pointer that pointed to something that was beyond the limit of your code segment. This means that the code segment limit was too low or you actually pointed over it. It's called RIP because the module that tells you what happened didn't bother to check whether you were in real mode, long mode, protected mode or whatever. The register in the virtual cpu that overflowed is RIP, so it'll tell you RIP is over the CS.limit.

Ah, my bad. Always thought of it as the return pointer in the stack. But i guess techically its not. Thanks for the correction.

i always thought rip meant Requested Insturction Pointer

Jordan3 wrote: i always thought rip meant Requested Insturction Pointer

You're probably thinking of RPL: Requestor Privilege Level. It's a different thing entirely.

Sorry if I added to the confusion about the returning part, I just meant that in my experience it was due to returning to somewhere that didn't exist due to messing the stack up, not that it actually meant Return Instruction Pointer or some derivative.

Kemp wrote: Sorry if I added to the confusion about the returning part, I just meant that in my experience it was due to returning to somewhere that didn't exist due to messing the stack up, not that it actually meant Return Instruction Pointer or some derivative.

I think you can also get it if you overrun the code segment, or if you jump over its boundaries. Both are less likely to happen though.