OSDev.org

Hi everybody !

Now that I've finally got long mode code to run, I'm currently in the process of fixing minor bugs, cleaning up code, and investigating strange behaviors.

Two things are puzzling me at the moment. I wonder if it's my code or Bochs which is to blame and wanted to ask here before reporting a bug on Bochs' website :
-> If a stack segment with its W bit cleared is loaded in long mode, bochs will triple fault because a non-writable stack segment has been loaded. Isn't this in direct contradiction with the AMD manual which reads "The expand-down (E), writable (W), and accessed (A) type-field attributes are ignored." (Vol 2, p.88) ?
-> In long mode, when displaying processor state, Bochs says : "[CPU0 ] CS.d_b = 16 bit". However, about the D bit, the AMD manual reads : "If the processor is running in 64-bit mode (L=1), the only valid setting of the D bit is 0. This setting produces a default operand size of 32 bits and a default address size of 64 bits. The combination L=1 and D=1 is reserved for future use." (Vol 2, p.87). Doesn't this mean that Bochs should say something like : "[CPU0 ] CS.d_b = op 32 bit, add 64 bit" ?

-> If a stack segment with its W bit cleared is loaded in long mode, bochs will triple fault because a non-writable stack segment has been loaded. Isn't this in direct contradiction with the AMD manual which reads "The expand-down (E), writable (W), and accessed (A) type-field attributes are ignored." (Vol 2, p.88) ?

It's not a bochs bug. I saw a similar thing on VMWARE and on real hardware. I found that when I did an iretq that if the destination SS was not writable I would get a GPF. So I think that while during memory accesses the W bit is never consulted, during iretq while loading a new SS, the W bit must definitely be set. See Intel 2A page 3-540.

Okay. About the other one, can I safely assume it is a bug from Bochs ?

The message literally says that the D bit is set to 16-bit, which is correct as it indeed holds the value you'd expect in 16-bit mode.