debugging on a real pc [FIXED]

[GLneo]

hi all, well my kernel just got some basic paging and it works on all emulators i can find, but it crashes on real PC's ? Normally i can move a "jmp $" around and compile and emulate in 20 sec and find the problem command and find the bug. now I'm going to have to do some debugging on a real PC, which may take 10 min to make a floppy disk, shutdown my pc, boot, and get windows back up to the point where i can compile and start the process over, i was thinking i could use my keyboard LED's and hotkeys to move stuff around but i was wondering if any of you have come up with a cool way to debug on a real PC with no text display?

thx!

[muisei]

Try with a 'print' function.Print something before and after every operator and you'll see where is the problem.

Update:I've read somewhere for debugging methot using serial com port, but for the purpose you'll need a second PC.

[Combuster]

without text display is rather difficult: i normally would poke bytes into video memory to see where things lock up.

That means you either find a different way of outputting. Some crazy ideas include doing knight rider on your keyboard or playing your favorite song on the pc speaker and see where it stops/hangs.

In the meantime, have you tried virtual machines instead of emulators. They save you from the slow reboot cycle... Also, you might find a spare box useful

Also, i have a garbage stub in my kernel that sets all memory to 0xCCs (credits to Brendan for the idea) which causes a lot of extra bugs to appear in emulators that normally only show on real hardware.

[Dex]

You use this:

Code: Select all

mov   byte [es:0xB809E], "1"
;some code
mov   byte [es:0xB809E], "2"
;some code
mov   byte [es:0xB809E], "3"
;some code
mov   byte [es:0xB809E], "4"
;some code

From pmode
Or this

Code: Select all

beep:
       pushad
        call  Sound
        call  DeLay
        call  NoSound
        popad
        ret

 ;----------------------------------------------------;
 ; Sound                                              ;
 ;----------------------------------------------------;
Sound:
        mov   bx,[Hz]
        mov   ax,0x34dd
        mov   dx,0x0012
        cmp   dx,bx
        jnc   Done1
        div   bx
        mov   bx,ax
        in    al,0x61
        test  al,3
        jnz   A99
        or    al,3
        out   0x61,al
        mov   al,0xb6
        out   0x43,al
A99:
        mov   al,bl
        out   0x42,al
        mov   al,bh
        out   0x42,al
Done1:
        ret
 ;----------------------------------------------------;
 ; NoSound                                            ;
 ;----------------------------------------------------;
NoSound:
        in    al,0x61
        and   al,11111100b
        out   0x61,al
        ret

 ;----------------------------------------------------;
 ; DeLay.                                          ;
 ;----------------------------------------------------;
DeLay:
        mov   ecx,0xffff                                  ; Mov ecx, number of loops
BusyDelay:                                           
        nop                                             ; Do a null operation(xchg ax,ax)
        nop                                             ; Do a null operation(xchg ax,ax)
        nop                                             ; Do a null operation(xchg ax,ax)
        nop                                             ; Do a null operation(xchg ax,ax)
        loop  BusyDelay                             
        ret

You will need to get key press before calling beeps, you can than count the beeps.

[GLneo]

i would like to try the garbage memory idea, how do i do that in 16 bit asm ( in my boot loader )

thx

[Combuster]

you can only trash parts of the lower memory from real mode...

untested:

Code: Select all

; destroyed regs: ax cx dx si di
; destroyed segregs: es
mov si, 0x0800
mov dx, 18      ;18 32k blocks
mov al, 0xcc    ;garbage
cld
loop:
mov es, si      ;load segment to fill
xor di, di
mov cx, 0x8000
rep stosb       ;fill with 0xcc's
add si, 0x800   ;go to next 32k block
dec dx
jnz loop
;if I counted correct, its 29 bytes

this should trash 00008000-00098000 (and thus leaving the locations where the bios keeps its stuff untouched)

[GLneo]

ok, after getting two computers together, which sped things up a bit, i have isolated the problem:

Code: Select all

 SECTION .text
 start:
;     mov esp, _K_stack
     mov edi, bss
     mov ecx, bsslength
     xor eax, eax
     cld
     rep stosd
     call _main_code
     jmp $
             

Code: Select all

void main_code()
{
    unsigned int start, end;
    asm("rdtsc\n":"=a"(start):);
//    logo();
    cls();
    start_computer();......

when i put a "jmp $" before "call _main_code" the real pc locks up( which is good becouse execution got to the "jmp $" ) but if i put "for(;;);" after " void main_code()" it reboots ( meaning the problem is before it got to "for(;;);"), does any one know why this jump would work on bochs and qemu but not on a real pc???

thx!

[uglyoldbob]

Why is the code setting up your stack commented out? That would cause that problem in a heartbeat (C/C++ use the stack for local variables and arguments. No stack = fail to execute properly)

[GLneo]

it's commented out because _K_stack is an array in my .bss and my stack during startup it grows tough my .data and kills my kernel... so now i just "mov esp, 090000h" in my boot sector, but thx for the try!

[deadmutex]

Hmm that's strange... Are you sure that '_main_code' is a valid address?

[Candy]

Why is the code setting up your stack commented out? That would cause that problem in a heartbeat (C/C++ use the stack for local variables and arguments. No stack = fail to execute properly)

Actually, on a fairly modern computer, it'll reboot a lot faster than a heartbeat.

[GLneo]

how would i check if '_main_code' is a valid address, it must be sorta valid it works on bochs + qemu, also is 090000h a good place for my stack?

[Kenny]

I had a similar error to this when I first started mixing C and assembly, I finally tracked down the cause of my problem to the "for ( ; ; )" command itself.

I found, by using a disassembler (ndisasm) on my compiled C kernel, that my compiler wasn't putting in a relative jump for the infinite loop, it was putting in an absolute jump to a specific memory location.

With a little more digging, I realised that I was compiling the C code for one base location, then loading it somewhere else in memory by accident.

When the processor jumped into the C code, the infinite loop jump was jumping to an unexpected offset in memory, and the real computer triple-faulted and reset.

I'm afraid this wouldn't explain why the emulators worked correctly though.

Hope this helps

[GLneo]

well i think i found the problem, the PC i was doing a lot of testing on is bad at booting ( it wont boot Slackware 11.0 ) but i found some more PC's and it seems the PC's i was trying it on were just bad at booting,

thanks for everyones help!