system doesn't stop!

[GLneo]

hi all, ok, i have had a fault handler for a some time, but now i have made some changes and it no longer stops the system at a fault, heres some code:
the command "breakpoint":

Code: Select all

_breakpoint:
    iret

this should mess up the stack and smash the system. this gets called:

Code: Select all

void isr_handler(struct registers *r)
{
    void (*handler)(struct registers *r);
    if (r->int_no < 32)
    {
        printf("\n\n\n\n\n\n\n\n\n\n");
        printf("EAX: 0x%h ", r->eax);
        printf("EBX: 0x%h ", r->ebx);
        printf("ECX: 0x%h ", r->ecx);
        printf("EDX: 0x%h\n", r->edx);
        printf("EDI: 0x%h ", r->edi);
        printf("ESI: 0x%h ", r->esi);
        printf("EBP: 0x%h ", r->ebp);
        printf("ESP: 0x%h ", r->esp);
        printf("EIP: 0x%h\n", r->eip);
        printf("EFLAGS: %b\n", r->eflags);
        printf("ERROR: \"%s\"", sys_ex_messages[r->int_no]);
        __asm volatile("cli\n"); // <----------------------------
        __asm volatile("hlt\n"); // <---------------------------
    }
    if(r->int_no >= 32 && r->int_no <= 47)
    {
        handler = irq_pointers[r->int_no - 32];
        if (handler)
            handler(r);
        if (r->int_no >= 40)
            outport(0xA0, 0x20);
        outport(0x20, 0x20);
    }    
}

the system does weird things, not stoping?

just type "breakpoint" with included image
(dont mind the extention, it's a .img, but it wont let me upload that:)

thx

[YeXo]

Does it print out a register dump? In other words, are you sure your isr_handler function is actually called?

[GLneo]

yes, it does print out a register dump, but over and over again, not stoping after 1 register dump like it should

p.s. this site won't let me upload my image?

[nick8325]

Does the cli; hlt appear in the object file? I wonder if GCC thinks it's not doing anything and has decided to get rid of it...try __asm__ volatile("cli; hlt" : : : "m") to see if that makes any difference.

Also, does it finish making the register dump? e.g. if printf("ERROR: ", ...) was faulting, it would print out the start of the dump and then fault almost at the end. Then the fault handler would print out almost all of the dump again...and so on.

[GLneo]

i've tryed __asm__ volatile("cli; hlt" : : : "m") but it sayed "m" is not a valid register? i looked at the disasm and the cli hlt was still there. good idea about it could be printf fault, so i made a command in the kernel that just cli; hlt;, the system should lock right after this, but it doesn't, it returns from the command and prints the shell text, THEN locks up?

[nick8325]

Oh sorry, I should have checked before I posted - "m" should be "memory" instead. If the instructions are in the object file though, it shouldn't make any difference.

Your shell not locking up is very strange...I can't really think of any reason why it would do that...you could try stepping through your code in the Bochs debugger to see what it's doing.

[GLneo]

how do you step through in the Bochs? i never figured that out

[nick8325]

You need the debugging version of Bochs. You can get that by configuring it with --enable-debugger --enable-disasm or using bochsdbg.exe on Windows.

Then when you run it, instead of starting up it should have a prompt in the console window. There are instructions to use it at http://bochs.sourceforge.net/doc/docbook/user/internal-debugger.html. Probably you should find out the address of your cli; hlt, and use pbreak to put a breakpoint at that address, then use continue to start Bochs running until the breakpoint, then use si to see what happens after there.

[paulbarker]

This looks to me as if the exception handler is being repeatedly called. Is the value of ESP decreasing each time it is printed, indicating that a number of stack frames are being built up, or is it roughly constant?

[GLneo]

qemu SUCKS!!! bochs does stop with the command "stop"!, but qemu ignores hlt's??? but my fault handler still fails, but in bochs with out printing the name of the error, but qemu does???

p.s. i wish this site would let my post the .img file because this is cool how different emulators do such different things

[distantvoices]

First, I'd like you not to issue unqualified comments towards qemu (qemu sucks & sorta). Grow up a bit and get used to try, error, try, error until you succeed. get used to do a bit of homework in case something difficult to understand arises.

You happen to keep getting the exception spinning around? that's simply because after the handler is done, the previous state is restored and eip still points to the faulting instruction, as exceptions don't advance it as would an interrupt.

you can also put in something like wait_on_key to step throu the thing. That's a tad bit easier for debugging weird stuff.

stay safe

[OZ]

if you just want them to stop why not use:

Code: Select all

for(;;)__asm__("hlt");

that works with bochs and qemu aswell.
If you issue a 'cli' before that should be almost the same a simple 'hlt' without the loop shouldn't it? (Apart from qemu looping forever instead of halting)

[Pype.Clicker]

p.s. i wish this site would let my post the .img file because this is cool how different emulators do such different things

chances are the .img file is over the 30KB limit for attachments. Put your image on your own website (e.g. sf.net) and point us there

[GLneo]

ok i figured out you can upload zip's, i have tryed the stop command on some pc's and on bochs and they all work, but qemu does not???

p.s. i said qemu sucks because i have been using bochs and qemu, and bochs seems to rum much more like a real computer(whitch is what an emulator is for), sorry if that offended any one who likes qemu

[Pype.Clicker]

okay. glad to have your image running in my Qemu, but with that alone, i don't see what you can expect from us except "oh, he's right: when i type "stop", the system gets back to the prompt" ...

that being said, even if the system returns to the prompt, i cannot type anything anymore, and tracing the execution with gdbserver command seems to show we're in an endless "hlt" loop ...