Hi! It's indeed better to open a new thread for this. So, here's my test session: $ qemu -fda extlinux.144 -s -S Then in another terminal: $ gdb extlinux.elf (gdb) set architecture i8086 (gdb) target remote localhost:1234 Remote debugging using localhost:1234 0x0000fff0 in ?? () at localboot.inc:68 68 jmp kaboom ; If we returned, oh boy... How does "jmp kaboom" get here? We are at the BIOS entry point: (gdb) display/10i $cs*16+$eip 1: x/10i $cs * 16 + $eip 0xffff0: ljmp $0xf000,$0xe05b [...] (gdb) info symbol 0x7c00 bootsec in section .text (gdb) b bootsec Note: breakpoint -2 also set at pc 0x7c00. Breakpoint 1 at 0x7c00: file extlinux.asm, line 146. Breakpoint -2? That's new for me. Anyway: (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. 0x000005a7 in ?? () 1: x/10i $cs * 16 + $eip 0xf05a7: push %bp 0xf05a8: mov %sp,%bp 0xf05aa: push %bx 0xf05ab: push %ds 0xf05ac: mov 4(%bp),%ax 0xf05af: movl %ax,%ds 0xf05b1: mov 6(%bp),%bx 0xf05b4: mov (%bx),%ax 0xf05b6: pop %ds 0xf05b7: pop %bx (gdb) bt #0 0x000005a7 in ?? () #1 0x00404dc6 in ?? () #2 0xfedf001c in ?? () #3 0x001ef000 in ?? () #4 0x003e001e in ?? () #5 0x7b66001e in ?? () #6 0x7b654c5c in ?? () #7 0x00007b64 in __stack_start () #8 0x11a8f000 in ?? () #9 0x00000000 in ?? () Now that doesn't buy me much... (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. pollchar () at conio.inc:289 289 mov dx,[SerialPort] 1: x/10i $cs * 16 + $eip 0x97e2 <pollchar+8>: mov 11242,%dx 0x97e6 <pollchar+12>: and %dx,%dx 0x97e8 <pollchar+14>: je 0x9801 <pollchar.done> 0x97ea <pollchar+16>: add $0x5,%dx 0x97ed <pollchar+19>: in (%dx),%al 0x97ee <pollchar+20>: test $0x1,%al 0x97f0 <pollchar+22>: je 0x9801 <pollchar.done> 0x97f2 <pollchar+24>: inc %dx 0x97f3 <pollchar+25>: mov 14758,%ah 0x97f7 <pollchar+29>: in (%dx),%al (gdb) bt #0 pollchar () at conio.inc:289 That doesn't either. Do I ask too much from my good ol' GDB when I need a stack trace? Is there a way I can hint it perhaps? Otherwise, I would be interested to read how you debug com32 modules. -- Thanks, Feri.
> $ qemu -fda extlinux.144 -s -Sqemu.exe -L . -hda extlinux.img -s -S Which qemu version are you using?> Then in another terminal: > > $ gdb extlinux.elfWhich gdb version?> (gdb) set architecture i8086 > (gdb) target remote localhost:1234 > Remote debugging using localhost:1234 > 0x0000fff0 in ?? () at localboot.inc:68 > 68 jmp kaboom ; If we returned, oh boy... > > How does "jmp kaboom" get here? We are at the BIOS entry point:I don't get that. With qemu snapshot from 2006-06-23 and gdb 6.8-debian i have: $ gdb extlinux.elf (gdb) target remote ip:1234 Remote debugging using ip:1234 0x0000fff0 in ?? () (gdb) set architecture i8086 The target architecture is assumed to be i8086 No kaboom.> (gdb) display/10i $cs*16+$eip > 1: x/10i $cs * 16 + $eip > 0xffff0: ljmp $0xf000,$0xe05b(gdb) x/1i $cs*16+$eip 0xffff0: ljmp $0xf000,$0xe05b> (gdb) b bootsec > Note: breakpoint -2 also set at pc 0x7c00. > Breakpoint 1 at 0x7c00: file extlinux.asm, line 146. > > Breakpoint -2? That's new for me. Anyway:(gdb) break start Breakpoint 1 at 0x7c5a: file extlinux.asm, line 199.> (gdb) c > Continuing. > ^C > Program received signal SIGINT, Interrupt. > 0x000005a7 in ?? () > 1: x/10i $cs * 16 + $eip(gdb) c Continuing. Breakpoint 1, start () at extlinux.asm:199 199 cli ; No interrupts yet, please (gdb) list 194 ; 195 ; Note we don't check the constraints above now; we did that at install 196 ; time (we hope!) 197 ; 198 start: 199 cli ; No interrupts yet, please 200 cld ; Copy upwards 201 ; 202 ; Set up the stack 203 ;> That doesn't either. Do I ask too much from my good ol' GDB when I > need a stack trace? Is there a way I can hint it perhaps?(gdb) break getonesec Breakpoint 2 at 0x7cf6: file extlinux.asm, line 330. (gdb) c Continuing. Breakpoint 2, getonesec () at extlinux.asm:330 330 mov bp,1 ; One sector (gdb) bt #0 getonesec () at extlinux.asm:330> Otherwise, I would be interested to read how you debug com32 modules.Same as above, but set the breakpoint on main and run the module, e.g.: $ gdb pcitest.elf (gdb) target remote ip:1234 Remote debugging using ip:1234 0x0000fff0 in ?? () (gdb) break main Breakpoint 1 at 0x10112e: file pcitest.c, line 100. (gdb) c Continuing. Run pcitest.c32. Breakpoint 1, main (argc=1, argv=0x183dd4) at pcitest.c:100 100 { (gdb) list 95 pci_bus_list->count, 96 pci_bus_list->count == 1 ? "" : "es"); 97 } 98 99 int main(int argc, char *argv[]) 100 { 101 struct pci_device_list pci_device_list; 102 struct pci_bus_list pci_bus_list; 103 openconsole(&dev_null_r, &dev_stdcon_w); 104 (gdb) break openconsole Breakpoint 2 at 0x101cd0: file sys/openconsole.c, line 39. (gdb) c Continuing. Breakpoint 2, openconsole (idev=0x1035d0, odev=0x1035b8) at sys/openconsole.c:39 39 { (gdb) bt #0 openconsole (idev=0x1035d0, odev=0x1035b8) at sys/openconsole.c:39 #1 0x00101150 in main (argc=<value optimized out>, argv=<value optimized out>) at pcitest.c:103 (gdb) - Sebastian
Ferenc Wagner wrote:> Hi! > > It's indeed better to open a new thread for this. So, here's my test > session: > > $ qemu -fda extlinux.144 -s -S > > Then in another terminal: > > $ gdb extlinux.elf > (gdb) set architecture i8086 > (gdb) target remote localhost:1234 > Remote debugging using localhost:1234 > 0x0000fff0 in ?? () at localboot.inc:68 > 68 jmp kaboom ; If we returned, oh boy... > > How does "jmp kaboom" get here? We are at the BIOS entry point: > > That doesn't either. Do I ask too much from my good ol' GDB when I > need a stack trace? Is there a way I can hint it perhaps? > > Otherwise, I would be interested to read how you debug com32 modules.Com32 modules is one thing. Qemu+gdb generally work well with those (although you may have to remove -fomit-frame-pointer from the relevant C compiler options). Debugging the core under gdb I find pretty hopeless, because gdb doesn't handle segmented memory at all. As I mentioned, I tend to use the Bochs builtin debugger instead. Getting a stack trace in the core is also pretty hopeless. However, examining the stack manually can usually tell you were you ended up from. -hpa