2

Considering we have an x86 processor and an OS that is using segmentation for memory management, for the sake of simplicity our segment boundary is 0xfff what happens when a process accesses a DWORD at boundary?

As x86 can access 32bit of data in one cycle will it just decode the instruction check if the specified address is in the boundary and give us a DWORD (from memory location 0xfff 0x1000 0x1001 0x1002 0x1003) or will it detect this memory violation? I've tried this on an online 8086 emulator with a WORD and it doesn't seem to detect it.

Edit: I am not asking about what will happen on an emulator, i am asking about what will happen on a 32bit physical processor.

Hououin_kyouma
  • 29
  • 3
  • 2
    Which emulator did you use? QEMU for example doesn't check segment limits for reasons of speed etc. BOCHs does check them. – Michael Petch Dec 08 '22 at 07:43
  • 3
    The answer to your question is in the Intel IA32/Intel 64 architecture software development manual in Vol 3a on bottom of page 4-6 and page 4-7. A #GP is raised if you are dealing with anything but an expand down segment and an encodable address spans across the segment limit. In 64-bit mode there are no limit checks. https://www.intel.com/content/dam/support/us/en/documents/processors/pentium4/sb/25366821.pdf . Not all emulators do the checks, so we'd need to know which one you used. – Michael Petch Dec 08 '22 at 07:53
  • 1
    @MichaelPetch I think QEMU does check limits if you're running it with KVM, but does not otherwise. Similarly, dosemu2 does not check limits in its interpreter or JIT translation, but does check limits if running in V86M (32-bit host only) or KVM or in native DPMI mode. – ecm Dec 08 '22 at 08:41
  • 1
    @ecm yes, if KVM is on and supported the `-enable-kvm` option in QEMU would catch it. Ultimately the reason I asked which environment is because knowing that one can say why it didn't yield a general protection fault when ir should have. – Michael Petch Dec 08 '22 at 08:44
  • 1
    8086 doesn't have segment limits since it doesn't have protected mode. – prl Dec 08 '22 at 10:28
  • 1
    @prl: If you access a word at `seg:FFFF` on 8086, does the offset wrap, or does it access one byte past the end of the 64K segment? Is it different on 286/386 in pure real mode, with segment limits at 64K? Probably my answer on [Segment size in x86 real mode](https://stackoverflow.com/q/17786357) should get updated with details like that; I didn't check manuals when writing it. (As far as this question, I guess the same thing applies for dword accesses even in 16-bit code, like from `lds` / `les` far-pointer loads, or x87 dword/qword/tbyte load/store on 8086 vs. 286/386.) – Peter Cordes Dec 08 '22 at 15:32
  • 1
    Since 286+ a memory access must be fully contained in a segment or a GP is raised in real and protected mode. The 8086 fetches unaligned words with two accesses but I'm not sure if the second step just increments the physical address or recomputes it from the logical address (which would result in accessing the first byte of the segment). I have a feeling it's the latter. – Margaret Bloom Dec 08 '22 at 18:26
  • 1
    @PeterCordes : OS/2 Museum discusses this https://www.os2museum.com/wp/does-eip-wrap-around-in-16-bit-segments/ – Michael Petch Dec 08 '22 at 21:48
  • @MichaelPetch: Thanks, updated [Segment size in x86 real mode](https://stackoverflow.com/q/17786357). Please let me know or edit my answer if I got anything wrong, if you have time to review it. – Peter Cordes Dec 08 '22 at 22:20

0 Answers0