lgdt not loading gdtr

[Agares]

Hello!
I'm writing my kernel in Visual Studio 2010(express), running from GRUB. I'm trying to load my GDT, with this code:

Code: Select all

	GDTPointer pointer;
	pointer.Limit = (5*sizeof(GDTEntry))-1;// 1 less than size of the table they said
	pointer.Offset = (uint32)&entries;
	GDTPointer *gdtPtr = &pointer;
	
	out << "Setting up GDT" << "\n";
	out << "Limit: " << (unsigned int)gdtPtr->Limit << "\n";
	out << "Offset: " << (unsigned int)gdtPtr->Offset << "\n";

	__asm {
		cli
		mov eax, gdtPtr
		lgdt eax
		push 0x8
		push reload
		retf
reload:
		mov ax, 0x10
		mov ds, ax
		mov ss, ax
		mov es, ax
		mov fs, ax
		mov gs, ax
		sti
	}

GDTPointer is defined like so:

Code: Select all

#pragma pack(push, 1)
struct GDTPointer {
	uint16 Limit;
	uint32 Offset;
};
#pragma pack(pop)

My problem is, that triple fault is issued. This is log form bochs:

Code: Select all

00045560726e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x
06)
00045560726e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x
0d)
00045560726e[CPU0 ] interrupt(): gate descriptor is not valid sys seg (vector=0x
08)
00045560726i[CPU0 ] CPU is in protected mode (active)
00045560726i[CPU0 ] CS.mode = 32 bit
00045560726i[CPU0 ] SS.mode = 32 bit
00045560726i[CPU0 ] | EAX=005ffd87  EBX=00033640  ECX=00100e08  EDX=0000009d
00045560726i[CPU0 ] | ESP=005ffd7b  EBP=005ffd93  ESI=005fffee  EDI=00033708
00045560726i[CPU0 ] | IOPL=0 id vip vif ac vm RF nt of df if tf sf ZF af PF cf
00045560726i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00045560726i[CPU0 ] |  CS:0008( 0001| 0|  0) 00000000 ffffffff 1 1
00045560726i[CPU0 ] |  DS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00045560726i[CPU0 ] |  SS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00045560726i[CPU0 ] |  ES:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00045560726i[CPU0 ] |  FS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00045560726i[CPU0 ] |  GS:0010( 0002| 0|  0) 00000000 ffffffff 1 1
00045560726i[CPU0 ] | EIP=0010076a (0010076a)
00045560726i[CPU0 ] | CR0=0x60000011 CR2=0x00000000
00045560726i[CPU0 ] | CR3=0x00000000 CR4=0x00000000
(0).[45560726] [0x000000000010076a] 0008:000000000010076a (unk. ctxt): xgetbv
                 ; 0f01d0
00045560726e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown
 status is 00h, resetting

info gdt says base is 0x0 and limit 65535. So my question is: what's going on? What did I do wrong? Where the hell did that xgetbv come from?

[Brendan]

Hi,

info gdt says base is 0x0 and limit 65535.

This makes me wonder if it crashed before the LGDT was executed.

So my question is: what's going on? What did I do wrong? Where the hell did that xgetbv come from?

Maybe the CPU is executing "trash" and the xgetbv has nothing to do with the problem. Maybe Visual Studio 2010 thinks it should be able to use AVX instructions.

My advice is to use Bochs debugger and put "xchg bx,bx" breakpoints wherever they make it easier to step through the code (e.g. immediately before the "lgdt"); so you can figure out where things go wrong.


Cheers,

Brendan

[Owen]

After the "00045560726e[CPU0 ] exception(): 3rd (13) exception with no resolution, shutdown" line, everything you read from Bochs will have been reset to the startup state.

I'd start by investigating why exception 0x6 is triggered.

[Agares]

OK. Thank you both very much for your help. My problem was, that I did lgdt eax, instead of lgdt [eax] (I still don't know why was is it interpreted as xgetbv). But that only happend accidentaly, while debugging. The real problem is that my GDT descriptors are wrong. What i thought before is that "info gdt" AFTER the exception will give me the state before the exception, so thanks for pointing that.

[Nable]

> I still don't know why was is it interpreted as xgetbv
These descriptor-registers instructions accept only memory-type operands and other encodings are reserved (i.e. cause illegal opcode exceptions) or decoded as other instructions (seems that it's your case).

Only question is "why did your compiler blindly generated encoding w/o any checks and warnings", although it's rather obvios: developers didn't waste time on checks about such rare instructions that are used by people who know deeply what they are doing".