idt and exceptions

[JustVic]

A little question. I made a little kernel wit idt realization.
Even keyboard are working.

But this c code not generate exceptions:

Code: Select all

int x = 5/0;

int f[4];
f[5] = 8;	

And with asm code any exception generated right:

Code: Select all

asm("int $0");

Help me understand why this can happen.

[8infy]

Code: Select all

int x = 5/0;

This either gets optimized out, or would end up generating a UD2 instruction.

Code: Select all

int f[4];
f[5] = 8;

What exception would you expect this to generate? You're just corrupting your own stack here.

Code: Select all

asm("int $0");

Yes, this makes sense

[alexfru]

This should generate a division by 0 exception:

Code: Select all

volatile int x = 0;
x = 1 / x;

[Octocontrabass]

This is guaranteed to generate a division by zero exception:

Code: Select all

asm("div %ah");

[JustVic]

It's been something with gcc optimization flags. I remove -O2 and all works. Sorry for late answer

[austanss]

It's been something with gcc optimization flags. I remove -O2 and all works. Sorry for late answer

Your exception handlers work. BUT DON'T REMOVE OPTIMIZATION. Instead, use the volatile keyword on lines you don't want optimized out.

[iansjack]

It's actually a very good idea to remove optimization whilst developing an OS. It makes it far easier to debug. Obviously, once you have your code running you will want to enable optimization. This may break things in which case it should be relatively easy to find the cause by comparing the optimized and non-optimized versions of the code.

[austanss]

I personally use -Ofast.

[nexos]

I agree with @iansjack. You should seperate Debug and Release builds. A debug build is built with -g and -O0. I've heard that GCC offers -Og for debug friendly optimizations, but I've also heard that it has its issues. A release build is built with -O3 and if you use assert -DNDEBUG. But using optimizations with debug build can cause problems with GDB. Also, compiling with -O3 on always may cover up some hidden bugs. This happened in my last OS. I compiled with -O3, and a bug went away, but with -O0, it occured every so often. Optimizations don't make sense .

[iansjack]

I personally use -Ofast.

That probably explains the number of problems you seem to have, particularly with regard to debugging. I wouldn't use such aggressive optimization until I was fairly sure that my code is correct.

Interestingly, a lot of people find that -Os produces not only the most compact code but also the fastest (but not until you've finished debugging).

[austanss]

I personally use -Ofast.

That probably explains the number of problems you seem to have, particularly with regard to debugging. I wouldn't use such aggressive optimization until I was fairly sure that my code is correct.

Interestingly, a lot of people find that -Os produces not only the most compact code but also the fastest (but not until you've finished debugging).

I dunno, optimizations have never been an issue for me. If I am really stumped on an issue I will try removing optimizations, but even then it still doesn't work.

[iansjack]

You just don't realize that they have been an issue. Your comments on gdb tell a different story to me.

But, hey - go with what works for you.

[nexos]

@iansjack is right. When I was working on an older kernel, GDB would jump around a lot when compiling with -O3. But not -O0.

[nullplan]

We are getting kind of off-topic, but: I always compile with full optimizations and debug using log messages instead of GDB. The GDB model is abhorrent to me, as it requires me to constantly test a version of the program I will not ship, and then ship a version I have not tested thoroughly. There is some observer effect to the log messages, yes, but there is a hell of a lot more to the mere use of GDB. If I do use debugging capabilities, I use those that show me what is actually going on, not what would be going on if this was a C64 and I was writing in BASIC.

[xeyes]

We are getting kind of off-topic, but: I always compile with full optimizations and debug using log messages instead of GDB. The GDB model is abhorrent to me, as it requires me to constantly test a version of the program I will not ship, and then ship a version I have not tested thoroughly. There is some observer effect to the log messages, yes, but there is a hell of a lot more to the mere use of GDB. If I do use debugging capabilities, I use those that show me what is actually going on, not what would be going on if this was a C64 and I was writing in BASIC.

Isn't the old fashioned standard practice thoroughly testing both debug and release builds and not releasing if there's issue in either?

If an issue do happen in both versions, I've seen many choose to fix the debug build first as it is more human friendly to not having to worry about the crazy optimizations and the debug build will almost always fail faster in a more debug-able state (if it didn't then more asserts are needed).

Nowadays though, the standard practice is probably "Testing is such a waste, if it seems to be almost working let's release it. The users will be our testers and we can push an update to fix any issue that the users complain about. We can even laugh at the users that dare to file bugs and close them as 'by design' 'no repro' or 'user error'"

Printf vs debugger does sound off topic, like some vi users refuse (or don't know the key combinations?) to use emacs kind of off topic?