Question about the GDT and Interrupts

[blackfireize]

Hey all,

I was trying to enable interrupts in my kernel recently, I initialized my GDT and IDT using Bran's tutorial.
Now, after I created some test ISRes and attempted to do

Code: Select all

asm volatile ("int $0x0");

Bochs triple-faulted and in the log the following was shown

Code: Select all

00033660559e[CPU0 ] interrupt(): not accessible or not code segment cs=0x0008
00033660559e[CPU0 ] interrupt(): not accessible or not code segment cs=0x0008
00033660559e[CPU0 ] interrupt(): not accessible or not code segment cs=0x0008

Now, this seems strange because I was able to use the GDT to do a far jump in my code via
(This was code I used to initialize the GDT)

Code: Select all

jmp 0x08:flush
flush:
      ret

Anyone have any idea why this is happening, and how I could fix it? Thanks in advance.

[invalid]

From Bochs sources:

Code: Select all

401     // descriptor AR byte must indicate code seg
402     // and code segment descriptor DPL<=CPL, else #GP(selector+EXT)
403     if (cs_descriptor.valid==0 || cs_descriptor.segment==0 ||
404         IS_DATA_SEGMENT(cs_descriptor.type) ||
405         cs_descriptor.dpl>CPL)
406     {
407       BX_ERROR(("interrupt(): not accessible or not code segment cs=0x%04x", cs_selector.value));
408       exception(BX_GP_EXCEPTION, cs_selector.value & 0xfffc);
409     }

Maybe it's the "dpl>CPL" triggering? Check Bochs output just before the fragment you quoted.

[blackfireize]

I'm guessing CPL is "Code protection level"? If so, then why would that be true, seeing as I am still in
ring 0 and I am initializing my GDT to have a DPL of 0.

I am so confused by this error, I honestly have no idea whats going on . I have validated the
GDT entries multiple times, yet bochs still complains that I don't have a valid code segment descriptor
in my GDT. I really need help...

[Combuster]

Apparently, your GDT is no longer valid at the time you call INT 0. So set a breakpoint there and dump the contents of the GDT and GDTR to see what's actually being done there.

[blackfireize]

Apparently, your GDT is no longer valid at the time you call INT 0. So set a breakpoint there and dump the contents of the GDT and GDTR to see what's actually being done there.

Well, certain function calls seem to be trashing the GDT. A call to printk (my printf)
seems to be trashing it. Could this be because of a call to va_arg (I was using the gcc
built-in functions for va_list, va_arg, etc....) also, when I call to install the IDT, it also
seems to trash it. However, not every function does this. Any ideas of why this might be happening? I will try dumping the contents of GDTR though. Thanks for the help.

[nevar]

Try to use bochs debugger command "watch write". It will insert breakpoint when there is write access to some memory address. Set it on your code descriptor entry in GDT.

[mmurfin87]

Go back through your GDT and IDT code and make sure you understand EXACTLY what each bit means. Read through your functions and make sure you completely understand what your set_gate functions are doing with the data you pass it.

Once you really understand this stuff, go back and make sure you're passing the correct data. My last problem took me 3 days to find and was as simple as passing 0x80 instead of 0x08. It doesn't stick out at you unless you (a) know exactly what that piece of data means with respect to how your set_gate functions are going to shift it to fit into your GDT and IDT structs and (b) look very carefully.

And of course, comment out everything but the most basic code, and slowly uncomment things until it crashes. Once it crashes, do the above to figure out why.

[blackfireize]

Just an update for anyone else who may be having this problem, for whatever reason my printk
function was trashing the GDT because it used the built-in va_arg from gcc. There seems to be
a myriad of other problems that are arising also, for example, installing my IDT made the GDT data
selector equal:

Code: Select all

GDT[0x02]=LDT

What does that even mean? It refers to the local descriptor table for the data descriptor? This seems
to be a never ending battle with me and my accursed GDT. Still, I am open to any advice..

[gerryg400]

My first thought is that your stack is not where you think it is.

[blackfireize]

My first thought is that your stack is not where you think it is.

Finally solved. It was a stack problem.

[qw]

I'm guessing CPL is "Code protection level"?

Current Privilege Level. It is the privilege level the code is actually running in. Usually it is equal to the Descriptor Privilege Level but it may be different in a conforming code segment.