How to set breakpoints in isr's in Bochs (Bran's kernel)

Pixion · Post by **Pixion** » Sat Dec 08, 2007 9:40 pm

Hi,

I am working through Bran's kernel tutorial and have it up and running under Bochs for debugging.

I set a breakpoint at 0x100000, as that is the address that kernel.bin is set to load. This breakpoint gets triggered as it is supposed to, and I can confirm that I am indeed at the entry of kernel.bin.

I used objdump to get the address of the common_isr_stub, which is the common part of all isr's that is run after the handler.

I thought that putting a breakpoint at this point would be a nice way to check any interrups that is occuring.

However, Bochs doesn't seem to trigger at this breakpoint, which seems a bit strange as for instance the timer int should be triggered quite a lot.

Instead, the kernel proceeds and shows the 'one second passed' message about once every second (actually its slower due to Bochs...). When I give a CtlC to stop the Bochs debugger by hand, it shows me that it is running the endless loop in the main() of the kernel:

Code: Select all


void main()
{
    int i;

    gdt_install();
    idt_install();
    isrs_install();
    irq_install();
    init_video();
    timer_install();
    keyboard_install();

    __asm__ __volatile__ ("sti");

    puts("Hello World!\n");

//    i = 10 / 0;
//    putch(i);

    for (;;);  //BOCHS STOPS HERE WHEN I HIT CTL-C
}

I used this command in Bochs: vb 0x8:0x0100104 (0x0100104 being the offset of the common stub I found via objdump).

I probably am missing something (are interrupts running in another code segment?).

Any help is appreciated.

bewing · Post by **bewing** » Sat Dec 08, 2007 11:27 pm

I'm using a slightly older version of bochs than the current one -- you may be using the same as me, perhaps. You cannot trust the breakpoints to fire. I almost always have to set TWO breakpoints.
So, I'd say -- when you are at the 0x100000 breakpoint, do a "disas" command to verify that the correct code is at your "common_isr" address -- then set breakpoints at the FIRST TWO addresses of that routine. The second breakpoint always fires, as far as I can tell. It seems to me that my version of bochs does not always test the breakpoint addresses immediately after calls or jumps.

Pixion · Post by **Pixion** » Sun Dec 09, 2007 12:09 am

Bewing,

Thanks, I think I saw that mentioned somewhere else as well.

It didn't work for the isr common stub, but I tried setting breaks at other points, which Bochs triggers o.k. (e.g. the irq common stub, as well as the basic routines that write strings to screen).

So, it may be the case that the isr common stub is not accessed at all in this particular kernel build (which is a bit strange...), but I will look how the timer triggered print-to-screen is implemented in the source.

I also may put in some div/0 code to trigger an exception, which should go through the irq0 routine (EDIT: isr0...), and see if Bochs traps it...

EDIT: I didn't realise the isr only handles exceptions, so as long as there are none (i.e. no div/o, page faults etc.) it will not be run... So I guess everything works as supposed to be...