GDT code - boom

[pcmattman]

Have you tried it?

[mystran]

There's no point in trying things that will just cause your linker to refuse to link stuff..

[pcmattman]

I still say, try it.

Either way, your Bochs log would definitely help in finding out exactly why you're having this problem and how to fix it.

[B.E]

Code: Select all

00017504444e[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00017504444e[CPU0 ] interrupt(): gate descriptor is not valid sys seg
00017504444i[CPU0 ] protected mode
00017504444i[CPU0 ] CS.d_b = 32 bit
00017504444i[CPU0 ] SS.d_b = 32 bit
00017504444i[CPU0 ] | EAX=00106814  EBX=0002bdc0  ECX=00000000  EDX=00000000
00017504444i[CPU0 ] | ESP=00106810  EBP=00106870  ESI=0002bf1a  EDI=0002bf1b
00017504444i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf ZF af PF cf
00017504444i[CPU0 ] | SEG selector     base    limit G D
00017504444i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00017504444i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 000fffff 1 1
00017504444i[CPU0 ] |  DS:0000( 0000| 0|  0) 00000000 000fffff 1 1
00017504444i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 000fffff 1 1
00017504444i[CPU0 ] |  ES:0000( 0000| 0|  0) 00000000 000fffff 1 1
00017504444i[CPU0 ] |  FS:0000( 0000| 0|  0) 00000000 000fffff 1 1
00017504444i[CPU0 ] |  GS:0000( 0000| 0|  0) 00000000 000fffff 1 1
00017504444i[CPU0 ] | EIP=001006fd (001006fd)
00017504444i[CPU0 ] | CR0=0x00000011 CR1=0 CR2=0x00000000
00017504444i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
00017504444i[CPU0 ] >> mov eax, dword ptr ds:0x100223 : A123021000
00017504444e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown status is 00h, resetting
00017504444i[SYS  ] bx_pc_system_c::Reset(SOFTWARE) called

from what I can uderstand from this is that DS isn't set (or is set to NULL), which would cause the general protection fault. In which case the code isn't even getting up to part of loading the GDT.

If this has change in the new version can someone post the new one. I'm also wondering, if you operating system is multi-tasking. It could be the TSS (or your process block) that may be causing this.

Anyway I got to get back to work

[pcmattman]

Try this before any GDT init:

Code: Select all

mov ax,0x10
mov cs,ax
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax

Note that SS should be a high value as well, as the stack grows downwards.

[ehird]

Code: Select all

gdt_flush:
	mov ax, 0x10
	mov cs, ax
	mov ds, ax
	mov es, ax
	mov fs, ax
	mov gs, ax
	mov ss, ax
	lgdt [gp]
	jmp 0x08:flush2

still boom

[~]

If on (Un)Real Mode, try:

Code: Select all

	lgdt [cs:gp]

[ehird]

Nope. GRUB launches me into protected mode.

[~]

Nope. GRUB launches me into protected mode.

Why don't you upload a disk image, and if possible the sources? Last time it was possible to help out and resolve for somebody through that sort of interaction in about 1 day.

[Combuster]

mov cs, ax

that can't even SAY boom. It just wont compile

[AJ]

Also, are you trying to switch segments before loading your own GDT? GRUB legacy documentation states that you can't rely on segment numbers or even the value of GDTR before you load your own GDT.

Adam

[mystran]

I still say, try it.

Trying things at random will at best give you code that works in some cases. The only way to build reliable code is to figure out why something does not work, and fix it based on the gathered information... not just randomly change stuff until something seems to run.

[mystran]

Try this before any GDT init:

Code: Select all

mov ax,0x10
mov cs,ax
mov ds,ax
mov es,ax
mov fs,ax
mov gs,ax

This won't work. CS can't be the same as the rest, plus as said, you can't load CS that way, as you have to use FAR-jump instead.

[mystran]

From the Bochs log above, it's obvious that since you are loading DS as the first new segment from the new GDT, and Bochs panics with invalid gate and DS=NULL in the register dump, your gate descriptor isn't valid, or your LGDT inststruction doesn't load the right stuff..

Interesting questions would be, do you have paging enabled, and if so, is your GDT mapped at the same address in physical and virtual memory?

If you scroll backwards in the Bochs log, what does it say about the LGDT? Enable CPU debug=log (in per-device log options) if it doesn't say anything. It could be simply that it fails to load the GDT if it's not aligned properly.

Code: Select all

struct gdt_ptr {
   unsigned short limit;
   unsigned int base;
} __attribute__((packed)); 

struct gdt_ptr gp; 

That won't get aligned right. You need to align it so that the 'base' (which is 4 bytes) get's properly aligned to 4 bytes. Easiest way to do it would be something like this:

Code: Select all

// You don't really need the attributes, since it'll get aligned to 4 anyway
// and since you have two shorts = 4bytes, and one int = 4bytes, it'll
// stay packed even without the attributes.
// They are good to have for documentation though, or in case future
// compiler versions start aligned differently.
struct gdt_ptr {
   unsigned short _dummy; // <- 2 bytes, to offset the alignment
   unsigned short limit;
   unsigned int base;
} __attribute__((aligned(4), packed));

struct gdt_ptr gp; 

If you still get tripple-fault after you've fixed that one, then there might also be something else wrong, but start by fixing that one.

edit: Also add 2 bytes to the address you load with LGDT, like this:

Code: Select all

   lgdt [gp+2]  // <- if I'm not mistaken, you want [] around it in Intel syntax? not sure to be honest

[/i]