Asserting that interrupts are enabled/disabled

[gsingh2011]

A bug I recently had would have been much easier to spot if had assert_interrupts_enabled() and assert_interrupts_disabled() functions.

My first question is how I would go about implementing assert?

My second question is how I would get the value of EFLAGS? If I can get it, then I can just do

Code: Select all

assert(EFLAGS & (1 << 8))

to implement these functions. I'm not sure how to return the value of a register from assembly.

[xenos]

The pushf instruction pushes the flags to the stack. So you could write an ASM function like this:

Code: Select all

GetEFlags:
    pushf
    pop eax
    ret

[gsingh2011]

It works! Thanks.

Here's how my assertion works in case anyone else wants to write one. I haven't written printf yet, so its a bit messy:

Code: Select all

#ifndef _ASSERT_H_
#define _ASSERT_H_

#include "screen.h"
#include "defs.h"

#define ASSERT(cond)                                       \
    do {                                                   \
        if (!cond) {                                       \
            set_text_color(RED, BLACK);                    \
            puts("Assertion '" #cond "' failed at line "); \
            puti(__LINE__);                                \
            puts(" of file " __FILE__);                    \
            asm("hlt");                                    \
        }                                                  \
    } while (0);

#endif

Do kernel panics usually just end in calling 'hlt', or is there a better way to do it?

[Nable]

> Do kernel panics usually just end in calling 'hlt', or is there a better way to do it?
If you want to stop execution completely then at least you should do `cli' before `hlt'.
If your OS supports SMP then you should probably send NMIs to other cores to stop execution fully (afaik, linux does so to prevent possible damage to data).

I don't like the way when assertion failure leads to unconditional system halt. It's better, for example, to wait for debugger connection (so we can at least try to retrieve more information about the error), in some situations it's even possible to recover (e.g., missed packet from PS/2 device).

Btw, afair, in linux panic() is separated from assert() because not all assertion fails are fatal, some of them just call bug() (shows a message in system log) and some call oops() (just message or panic depending on your config).

[gsingh2011]

I don't like the way when assertion failure leads to unconditional system halt. It's better, for example, to wait for debugger connection (so we can at least try to retrieve more information about the error), in some situations it's even possible to recover (e.g., missed packet from PS/2 device).

How would I stop execution without halting, so I could attach a debugger?

[Nable]

Did you try to search before asking this question?
I can suggest you this: http://wiki.osdev.org/GDB
And here is an extremely good alternative for beginners: http://wiki.osdev.org/Bochs#Magic_Breakpoint

[gsingh2011]

Did you try to search before asking this question?
I can suggest you this: http://wiki.osdev.org/GDB
And here is an extremely good alternative for beginners: http://wiki.osdev.org/Bochs#Magic_Breakpoint

I know how to set up remote debugging with GDB, but what I was looking for was something like magic breakpoints (so I can break instead of halt and then attach a debugger). But I use QEMU, and I can't find any similar functionality for it.