IDT & #GP

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
JFF

IDT & #GP

Post by JFF »

OK... this is my first post :P... so hi everyone ! I've read in my spare time for almost three years now about Operating Systems and tried many times to actually implement one... and now it's going well... started a month ago and i've done much (gdt,idt,mm, malloc, multithreading, pic,etc) but now i see the need for some debugging that I was NOT doing at all so its more like restarting for scratch than debugging ;).

This week I finally got my IDT to work without crashing bochs. I print each vectors when I set them (I print the vector in a function call set_exception which set the entry in the IDT - easier to debug) and then I enable interrupts and I get a General Protection Exception (#GP). If i comment the print instruction... everything goes right... no errors and CPU halts as supposed to be (i halt it because i have nothing to do now). And I was wondering what can cause this.... dump_cpu in bochs give me (eip is somewhere around or is the offset of the halt instruction in my exception handler but should be it since it halts) :

Code: Select all

eax:0x67db4   ebx:0x67d81   ecx:0xb8000   edx:0x0
ebp:0x67e5c   esi:0x0        edi:0x5b4c0       esp:0x67d70
eflags:0x6       eip:0x100139

cs:s=0x8, dl=0xffff, dh=0xcf9a00, valid=1
ss:s=0x10, dl=0xffff, dh=0xcf9200, valid=7
ds:s=0x23, dl=0xffff, dh=0xcff200, valid=7
es:s=0x23, dl=0xffff, dh=0xcff300, valid=1
fs:s=0x23, dl=0xffff, dh=0xcff300, valid=1
gs:s=0x23, dl=0xffff, dh=0xcff300, valid=1

ldtr:s=0x0, dl=0x0, dh=0x0, valid=0
tr:s=0x0, dl=0x0, dh=0x0, valid=0
gdtr:base=0x1000, limit=0xffff
idtr:base=0x12000, limit=0x7ff
dr0:0x0 dr1:0x0 dr2:0x0 dr3:0x0
dr6:0xffff0ff0 dr7:0x400
cr0:0x60000011 cr1:0x0 cr2:0x0 cr3:0x0 cr4:0x0
inhibit_mask:0
All entries in IDT are OK I double checked that, and they are all DPL0, 32bit trap gates.... selector = 0x08

Code: Select all

GDT :
GDT[0x01]=Code segment, linearaddr=00000000, len=fffff * 4Kbytes, Execute/Read, 32-bit addrs

GDT[0x02]=Data segment, linearaddr=00000000, len=fffff * 4Kbytes, Read/Write, Accessed

GDT[0x03]=Code segment, linearaddr=00000000, len=fffff * 4Kbytes, Execute/Read, 32-bit addrs

GDT[0x04]=Data segment, linearaddr=00000000, len=fffff * 4Kbytes, Read/Write, Accessed
others are NULL.

kprintf only modifies the video memory... there is only video routines... gdt... idt... string.h... remapping the PIC... all the other functions are commented right now... I'm trying to learn so I'd prefer be pointed to things to look for than giving out my code and someone replies with the correction.

JFF

P.S : I hope my english is still understandable it's like 3 AM ;)
Top
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:
Contact Pype.Clicker

Re:IDT & #GP

Post by Pype.Clicker »

something that troubles me is that your data selector is obviously with RPL=3 ... i'd say you should load them with 0x20 rather than 0x23 when in CPL0, though i should check intel manuals to make sure ...
Top
JFF

Re:IDT & #GP

Post by JFF »

Ok... i now load it with 0x20.... i'll check the intel manuals tomorrow....
Top
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:
Contact Brendan

Re:IDT & #GP

Post by Brendan »

Hi,
Pype.Clicker wrote: something that troubles me is that your data selector is obviously with RPL=3 ... i'd say you should load them with 0x20 rather than 0x23 when in CPL0, though i should check intel manuals to make sure ...
It is troubling at first glance, but code running at CPL=0 can load an RPL=3 data segment and use it without problems as long as the data segment's GDT entry has DPL=3. My OS sets all data selectors (not SS) like this so that they never need to be changed.

While JFF didn't provide much detail I assume DPL=3 is used for data segments as multi-threading, etc is working.
JFF wrote: This week I finally got my IDT to work without crashing bochs. I print each vectors when I set them (I print the vector in a function call set_exception which set the entry in the IDT - easier to debug) and then I enable interrupts and I get a General Protection Exception (#GP). If i comment the print instruction... everything goes right... no errors and CPU halts as supposed to be (i halt it because i have nothing to do now). And I was wondering what can cause this.... dump_cpu in bochs give me (eip is somewhere around or is the offset of the halt instruction in my exception handler but should be it since it halts) :
"dump_cpu" in bochs will show you the current EIP, which will be in your GPF exception handler. This doesn't tell you anything about the instruction that caused the GPF. The address of the instruction that caused the exception will be on the GPF handler's stack, along with an error code.

Could you post a stack dump and the instruction that causes the GPF?

From bochs you could use "x /48 0x67d70" (or whatever ESP happens to be) to get the stack dump. The stack dump will contain data from before the exception, then EFLAGS, CS, EIP, ERROR_CODE and then whatever your exception handler puts on top. The error code will also help in determining the problem...


Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Top
JFF

Re:IDT & #GP

Post by JFF »

I dont' have much time right now, but "x /48 0x67d70" gives me
<bochs:3> x /48 0x67d70
[bochs]:
0x00067d70 <bogus+ 0>: 0x00067db4 0x0000004f 0x00034900 0x00067df8
0x00067d80 <bogus+ 16>: 0x453e3e6d 0x70656378 0x6e6f6974 0x63634f20
0x00067d90 <bogus+ 32>: 0x64657275 0x20203a20 0x656e6547 0x206c6172
0x00067da0 <bogus+ 48>: 0x746f7250 0x69746365 0x46206e6f 0x746c7561
0x00067db0 <bogus+ 64>: 0x000a3c3c 0x0010221d 0x0000001f 0x00008f00
0x00067dc0 <bogus+ 80>: 0x00000a81 0x00000010 0x00034900 0x00100a5a
0x00067dd0 <bogus+ 96>: 0x0000000d 0x0005b4c0 0x00000000 0x00067e5c
0x00067de0 <bogus+ 112>: 0x00067df4 0x00034900 0x00000000 0x000b8000
0x00067df0 <bogus+ 128>: 0x00102277 0x00000020 0x00000020 0x00000020
0x00067e00 <bogus+ 144>: 0x00000020 0x00000103 0x00100b89 0x00000008
0x00067e10 <bogus+ 160>: 0x00010202 0x00102277 0x00002000 0x00007c00
0x00067e20 <bogus+ 176>: 0x00002000 0x00000000 0x00000000 0x00034900
I'll have a look when I'll come back...
Top
User avatar
Brendan
Member
Member
Posts: 8561
Joined: Sat Jan 15, 2005 12:00 am
Location: At his keyboard!
Contact:
Contact Brendan

Re:IDT & #GP

Post by Brendan »

Hi,
JFF wrote: I dont' have much time right now, but "x /48 0x67d70" gives me
Ok, if I'm right:
Eflags was 0x0010221d
CS was 0x0000001f
EIP was 0x00008f00
and the error code was 0x00000a81

The error code suggests that GDT entry 0x0A80 was involved, but it was something "external to the program" that caused the exception (e.g. an IRQ). This means you've probably got an interrupt gate or trap gate in the IDT that is trying to use GDT entry 0x0A80 when it can't.

Cheers,

Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
Top
User avatar
Pype.Clicker
Member
Member
Posts: 5964
Joined: Wed Oct 18, 2006 2:31 am
Location: In a galaxy, far, far away
Contact:
Contact Pype.Clicker

Re:IDT & #GP

Post by Pype.Clicker »

... which could be the symptom of a mispaired push/pop in the interrupt handler.
Top
JFF

Re:IDT & #GP

Post by JFF »

... it was something "external to the program" that caused the exception (e.g. an IRQ).
I looked at my init_pic function... and I wasn't disabling any of the IRQ... i disabled them and now everything works ;)


Thanks

?JFF
Top
Post Reply

Return to “OS Development”