osdevnewbie wrote:
In many tutos I've seen they did it the same manner with -1 !! cause we start counting from ZERO no?
While it is true that you subtract 1 when filling in the gdtp structure (the CPU internally will add 1 to that value to get the true size), when your own code is dealing with the actual structure you have to use its true size. So if you tell memcpy to copy 23 bytes it will copy 23 bytes. But the structure is actually 24 bytes. You need to deal in the real size, not the value passed through the
gdtp limit value.
osdevnewbie wrote:
Yes, using NASM and MINGW.
I could have guessed. If you build the code in a certain way you may not find the code fixes up reliocations as exepected. there is a part of me that thinks that may be the case here. I'm curious if when you stepped through your code whether you noticed if the
gdtp variable was filled in properly ahead of time. Although you say the `memcpy` worked (the data at 0x800 looks okay) I am under the impression that there is a problem with
gdtp. One thing you can do is use bochs to step to the instruction just past the `lgdt` and then issue the command `info gdt` in the debugger. If the `gdtp` variable was filled in properly it should result in output that is similar to this:
Code:
Global Descriptor Table (base=0x0000000000000800, limit=23):
The base ix 0x800 and limit 23. I suspect yours is not that at all since the dump of memory 0x800 looks correct BUT your Bochs debug output has this:
Code:
00017826504i[CPU0 ] | CS:0008( 0001| 0| 0) 00000000 ffffffff 1 1
00017826504i[CPU0 ] | DS:0010( 0002| 0| 0) ffffffff ffffffff 1 1
00017826504i[CPU0 ] | SS:0010( 0002| 0| 0) 00000000 ffffffff 1 1
00017826504i[CPU0 ] | ES:0010( 0002| 0| 0) ffffffff ffffffff 1 1
00017826504i[CPU0 ] | FS:0010( 0002| 0| 0) ffffffff ffffffff 1 1
00017826504i[CPU0 ] | GS:0010( 0002| 0| 0) ffffffff ffffffff 1 1
Of note is the fact that the base value is 0xffffffff for DS, ES, FS, GS. That's incorrect given that your base for the 0x10 descriptor is 0x00000000. This suggests to me that your
gdtp is wrong and is pointing at the wrong memory address for the address of the GDT and/or the limit is wrong
osdevnewbie wrote:
I've done that. The fault happens when executing: jmp 0x08:next.
According to the Bochs debugging output you provided the failure is actually on the
mov ss, ax instruction, not the JMP. The instruction is listed in the output as:
Code:
0x000000000000101d>> mov ss, ax : 8ED0
The 0x10 descriptor entry is effectively invalid and thus causes a fault to occur when moved into SS.