OSDev.org

Ok we've managed to get the stacks out of the way, there's another issue with the actual IRQ now. We've managed to break it down to 2 lines.
With the second commented out it throws invalid opcodes, and the second line appears to throw gpfs.

Steve the Pirate wrote:I had a problem where my keyboard ISR would run, and then immediately after I would get a GPF. What fixed it for me was turning down the compiler optimisation level.

Then your code is seriously broken. (tried the volatile keyword?)

Ok we've managed to get the stacks out of the way
(...)With the second commented out it throws invalid opcodes, and the second line appears to throw gpfs.

No, I fear you have not.

If your debugging attempts are sane (they're still incomplete - break at the interrupt, then singlestep through the entire ISR until it either returns or GPFs. its not THAT hard ), this is your interrupt handler:

add esp, 0x0000000c <- unmatched stack modification
pushad
popad
iretd <- this breaks since the stack points to the wrong location

Steve the Pirate wrote:I had a problem where my keyboard ISR would run, and then immediately after I would get a GPF. What fixed it for me was turning down the compiler optimisation level.

If you have to turn off optimizations, it means you have a problem with your code. You forgot to put a lock somewhere, or define something as volatile, etc. When you turn of optimizations, it does things slowly. If you are getting crashes while optimizations are on, you may want to track down the bugs now, rather than waiting until your OS is much larger and harder to track down. In OS dev, there isn't much difference in debugging something with optimizations on or off, unlike normal programming where you can't typically debug with optimizations turned on (debug vs. release builds).

Combuster wrote:add esp, 0x0000000c <- unmatched stack modification
pushad
popad
iretd <- this breaks since the stack points to the wrong location

Sorry, but that line was needed. He is using MSVC++ which, by default, adds some epilogue code to the beginning of the routine which pushes 12 bytes on the stack. add esp, 12 pops them off. (He may have put a break at the beginning of the routine after the epilogue code so it is not shown in his debugger).

Currently his IRQ is a naked function so no epilogue code is added. I also had him remove that code completley because it is not needed anymore.

However, the two lines that he posted is inside of his IRQ handler and is causing issues. Im not quite sure why though Some more debugging should answer it though.

The errors have been fixed. ^-^
Neon helped me out a lot, it turns out that variable wasn't being assigned correctly.
Turns out this was the reason for most of the errors.

There was a bunch of other small stupid errors that helped out to like interrupts were enabled when installing them...

Anyway, thanks guys. ^-^

He is using MSVC++ which, by default, adds some epilogue code to the beginning of the routine which pushes 12 bytes on the stack.

Oooh, shame on you. Writing ISRs in something other than assembly

Which shows again that you should be complete in your descriptions to make finding bugs easier.

Oooh, shame on you. Writing ISRs in something other than assembly

I don't quite know what the problem is with doing that. Considering that the code can be complied in different compiliers behind the preprocessor, as long as you know what the compiler does to your code its very easy to reverse it and have no problems at all. This should be an easy fix if you know the environment well, which is recommended for any OS developer anyways.

Unless there is another reason for it not mentioned in the Wiki?

Which shows again that you should be complete in your descriptions to make finding bugs easier.

Agreed. I originally had the OP post this because I was not sure what was going on and was thinking other members here may have ideas. I am to admit it is a bit hard to understand what is going on with this thread with the very little information posted. Sorry about that

neon wrote:

Oooh, shame on you. Writing ISRs in something other than assembly

I don't quite know what the problem is with doing that. Considering that the code can be complied in different compiliers behind the preprocessor, as long as you know what the compiler does to your code its very easy to reverse it and have no problems at all. This should be an easy fix if you know the environment well, which is recommended for any OS developer anyways.

The problem is, the compiler may decide to change its behaviour based on changes in your code which you might or might not anticipate. (like you being forced to keep optimisations off) By forcing a specific prologue/epilogue you save yourself a lot of trouble maintaining the code. It will also keep working that way if you change compilers (even versions)

Unless there is another reason for it not mentioned in the Wiki?

Mainly the experience that it regularly leads to problems by those using it, and that those problems are impossible to fix by looking at the source code alone. IMO it should also be common sense that you should not use the C calling convention when the function (read: ISR) is called by the x86's interrupt calling convention.

The problem is, the compiler may decide to change its behaviour based on changes in your code which you might or might not anticipate. (like you being forced to keep optimisations off) By forcing a specific prologue/epilogue you save yourself a lot of trouble maintaining the code. It will also keep working that way if you change compilers (even versions)

My code tends to work with all optimization levels...debug and release...

I do see your perspective though from a maintenance point of view. You would only need to write a standard single prologue/epilogue without needing to have different variants of it based on the compiler in use. Although this does not apply if you only plan to use a single compiler.

"tends" to work, ehehe

*ducksandruns*

I still suspect GCC of optimizing away the prologue and break everything if you give it enough reason to.

"tends" to work, ehehe

I should probably have said "always" works. ...right now, anyways (I sometimes (although not often) do run into problems related to optimization levels. None that cannot be fixed though. Then its back to working on all optimization levels again.)

I still suspect GCC of optimizing away the prologue and break everything if you give it enough reason to.

Mabey. I'm not using GCC though I am not sure if my code can be ported over to it either (My entire system is in C++). Please correct me if the GCC package includes a standards compliant C++ compiler (I have not used it in awhile). If it does then I may consider it some more

With this you imply that MSVC includes a C++ standard compliant compiler, which is not true.

Of course; there is no compilier that fully abids by the standard. However it does support (the newer MSVC compiliers, anyways) alot of the standard (Assuming you build with extensions disabled.)

(Please lets stop getting off topic here.)