OSDev.org

OK... this is my first post ... 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) :
All entries in IDT are OK I double checked that, and they are all DPL0, 32bit trap gates.... selector = 0x08 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

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 ...

Ok... i now load it with 0x20.... i'll check the intel manuals tomorrow....

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

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...

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

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

... 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