I see a lot of people in the forums and in the bug-
tracker talking about the RIP > CS.Limit error. Even I
have gotten this, but I understant that simply my code
caused this error; I've jumped beyond the size of my
code segment. This condition is noted as a General
Protection fault (even in real mode) by the CPU, and
raises a signal which the Intel IA32 Processor
Architecture Manuals label #GP. Why not, when
processor errors occur, that not only do you provide the
text of the error (e.g. RIP > CS.Limit) as well as #GP; so
the error would look like:
<some_address>[CPU ] #GP: EIP > CS.Limit</some_address>
Notice I've also changed RIP to EIP. I think that RIP is
simply a typo in the source code and that has been
bothering me for some time as well....there is no RIP
register, but there is an EIP, which could cause
confusion for some noobs out there (as it did I when I
was a noob).
This way, when an error occurs, the programmer can go
find the instruction causing the error, and with the help
of Intel's manuals, know excatly what error condition is
being signaled and how they're violating the CPU
function.
Respectfully submitted,
~ Craig
Logged In: YES
user_id=487634
About detailization of PANIC message to smh like
<some_address>[CPU ] #GP: EIP > CS.Limit
I will commit the change to the CVS today and it will be
release in Bochs bugfix 2.1.1 release.</some_address>
And about RIP register name, this is no typo and such a
register really exists. Together with RAX, RBX, RCX, RDX and
etc. Read AMD64 architecture manuals ;)
May be the register name should remain EIP when AMD64
simulation is disabled but are you sure that somebody really
need it ?
Thanks,
Stanislav
Logged In: YES
user_id=487634
After looking more deeply into the code ...
Bochs produces the PANIC message in CPU::prefecth
function. This mean that EIP out of CS.limits during
instruction prefeching operation. This condition could occure
in real CPU too and do not cause #GP exception. The
exception will be generated only if the cpu will fetch on
demand out of CS.limits. It is possible that in prefecthed block
of the code was some branch/call/ret instruction that
changes EIP and preserves the demand fetch from arriving to
CS.limit.
So firstly we should check that real CPU does in the above
case. And anyway, Bochs instruction prefetching is different
from prefcthing that real cpu does, so the problem should be
forwarded to the code owner.
I suggest you to post message in Bochs developers mailing list
and may be a solution will be found.
I am leaving your request open and unassigned.
Thanks,
Stanislav
Logged In: YES
user_id=487634
The problem with PANIC EIP > CS.Limit already fixed in CVS.
Stanislav