Page 1 of 1
Asserting that interrupts are enabled/disabled
Posted: Sat Oct 26, 2013 4:56 pm
by 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
to implement these functions. I'm not sure how to return the value of a register from assembly.
Re: Asserting that interrupts are enabled/disabled
Posted: Sun Oct 27, 2013 12:13 am
by xenos
The
pushf instruction pushes the flags to the stack. So you could write an ASM function like this:
Re: Asserting that interrupts are enabled/disabled
Posted: Sun Oct 27, 2013 4:14 pm
by 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?
Re: Asserting that interrupts are enabled/disabled
Posted: Sun Oct 27, 2013 5:26 pm
by 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).
Re: Asserting that interrupts are enabled/disabled
Posted: Sun Oct 27, 2013 6:01 pm
by 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?
Re: Asserting that interrupts are enabled/disabled
Posted: Sun Oct 27, 2013 6:50 pm
by 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
Re: Asserting that interrupts are enabled/disabled
Posted: Sun Oct 27, 2013 10:06 pm
by gsingh2011
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.