loop errors (GPF)

[suthers]

Ok so I've just started designing my PIC, so I want to write a keyboard driver...
But If the CPU is halted and IF = 0 at the end of my OS, I can't test the driver, so I decided to add a simple loop, So i tried:

Code: Select all

volatile int test = 10;

...

while(test != 0){};

This produced in asm:

Code: Select all

000004A8  8B442408          mov eax,[esp+0x8]
000004AC  85C0              test eax,eax
000004AE  75F8              jnz 0x4a8

But a GPF occurs.
When I trace it, it says that the GPF is cause by the test line, I don't understand how this is possible, any clues?
Thanks in advance,

Jules

[Combuster]

a GPF can also occur because of an misfiring interrupt. Have a look at the error code to see where that happens exactly.

[Korona]

It's _not_ possible. The GPF is most definitely caused by an interrupt. A halt instruction cannot cause GPFs. (At least not when it does not reference memory, see intel manuals)

[suthers]

Sorry, my fault, I just realized that the return value (EIP) pushed onto the stack during an interrupt for a GPF is the address of the instruction before the instruction that caused the fault, so its the conditional call that caused the GPF.... (sorry, stupid mistake..., thanks again to AJ for showing me sandpile.org)
I've tried different types of looping which generate different types of code such as a jmp that jmps onto its self, etc... all of them have a GPF caused by the various forms of jmp instructions used...., so I don't think it's an interrupt, that would be to much of a coincidence....
Any clues?
Thanks in advance,

Jules

[AJ]

It's _not_ possible. The GPF is most definitely caused by an interrupt. A halt instruction cannot cause GPFs.

Just to clear this up (I may be missing something but I don't see how this is relevant to the original question), a halt instruction can cause a GPF if you are in ring 3.

Cheers,
Adam

[Korona]

It's _not_ possible. The GPF is most definitely caused by an interrupt. A halt instruction cannot cause GPFs.

Just to clear this up (I may be missing something but I don't see how this is relevant to the original question), a halt instruction can cause a GPF if you are in ring 3.

Yes, sorry, I was talking about the test instruction ^^;;.

[Combuster]

Well, the only two reasons for an exception in this code is because ESP+xx is out of range, or the code is. With flat address spaces, neither should be a problem.

Will you please post the error code pushed as part of the GPF (and for completeness' sake, the other registers)

[suthers]

After a fewer hours of analysing stack output, I finally reallised why I had put 'add esp, 4'
So the error code popped onto the stack by the CPU when the GPF occurs is: 0x103
Thanks in advance,

Jules

P.S. I would have looked them up in the intel manuals, but I'm at school, when I try to load them, the terminal I'm on crashes so...., yah I should have them saved on my laptop, but the only one I have saved says under exceptions GP, it says lookup chapter five which in their infinite kindness is in another manual....(which I haven't downloaded...)

[Combuster]

its an external interrupt (bit 0), the entry number is 0x20. I don't know the other bits by hard, but it probably claims IDT entry #20 is borked. (try "info idt 32" in bochs)

Which makes completely sense

[suthers]

when i do info idt 32, it just gives me the base and the limit.
Which I don't think is very useful, but just incase:

Code: Select all

Interrupt Descriptor Table (base=0x00000000001004ee, limit=255):

Thanks in advance,

Jules

[suthers]

Oh I get it, It means give the info on the interrupt you pass to it (32)...
Sorry I'm really stupid sometimes....
Thanks, Combuster, thanks to you I'm fixing bugs and learning how to use bochs debugger...
And i don't have an 0x20 idt entry...
(Weird that it gives a value for it, i've gone through my kernel, that comes out somewhere in the middle of a string...)
But it is where I remapped my PIC (So that would be system timer...)
So I removed the PIC remap.
But I now get a divide by zero error (weird....) That comes from the same instruction....
Jules

[Combuster]

base=0x00000000001004ee

Yuck, unaligned table

So I removed the PIC remap.

Not remapping the PIC is considered a Bad Thing(tm). Now when you get interrupts it will look like you get exceptions instead of hardware interrupts, as they use the same vectors.

You'd better fill up the IDT entries with proper values to end up with a usable system.

[suthers]

Thanks, fixed, I filled the IDT with proper values, that fixed it, for some reason the timer interrupt fires once at the beginning of the loop...
Thanks to all,

Jules