Bug in Bochs?

[Igor1024]

I use Bochs 2.3.7 and noticed that when Bochs shows contents of registers (when #GP occurs, for example), it doesn't take into account granularity flag. I changed G flag at descriptor and Bochs showed the same result (it shows result like G flag is unset). It seems to be bug.
For instance:

Code: Select all

db 0FFh,0FFh,0,0,0,92h,0CFh,0;base 0; limit 0xFFFFF*1000h

is similar with:

Code: Select all

db 0FFh,0FFh,0,0,0,92h,04Fh,0;base 0; limit 0xFFFFF

[Igor1024]

I know it. But according to Bochs they are similar. That the tricky thing.
Is it bug? I think it is.

[stlw]

I know it. But according to Bochs they are similar. That the tricky thing.
Is it bug? I think it is.

Let me guess. You forgot to reload the descriptor after you changed it ?

Please next time try to understand things before you rush to file a bug report. You said nothing about your case, what are you doing and why, sure people would glad to help you and show you your problem.

Stanislav

[stlw]

One before you assumed it is AMD CPU bug instead

http://forum.osdev.org/viewtopic.php?f= ... hs#p190763

I think it is always better to think of your own issues before trying to blame your tools.

Stanislav

[Igor1024]

stlw, I didn't forget. I changed G flag at global data descriptor, but the field 'limit' at Bochs didn't change at all, howewer 'G' changed.
Bochs just prints this debug information wrongly (I said it before). It means that it can count G flag when providing operations, but when it prints base and limit of segments, field 'limit' there is wrong.

[stlw]

stlw, I didn't forget. I changed G flag at global data descriptor, but the field 'limit' at Bochs didn't change at all, howewer 'G' changed.
Bochs just prints this debug information wrongly (I said it before). It means that it can count G flag when providing operations, but when it prints base and limit of segments, field 'limit' there is wrong.

But because you cannot show your code as I already tried to hint you, nobody will be able to help you and show you where you were wrong ...

Stanislav