![]() To break on start_kernel and then trying to do `stepi`. I know it needs an initrd and a hdd img in order to boot a full system, but for me it was enough ![]() Qemu-system-i386 -kernel bzImage -S -s -append 'nokaslr' I built the kernel with buildroot and I launched QEMU with: Just to be sure, I tried to the Linux kernel 4.19.16 in the same scenario and I got the same result. I believe that the cross-arch scenario almost certainly has something to do with the bug, as it happened in the past on both sides (qemu and gdb). It's totally independent from that.įinal remark: note that I'm running gdb on x86_64 machine, while I'm debugging a kernel running on a i386 (virtual) machine. I'm sure the problem has been introduced in this specific version 'Ubuntu 8.1-0ubuntu3.1' and it's *not* related with QEMU *nor* with the kernel that is being debugged. Note: I downgraded exclusively GDB back to version 'Ubuntu 8.1-0ubuntu3' in order to check if the problem would be fixed and it is. Warning: Breakpoint address adjusted from 0xc0115a45 to 0xffffffffc0115a45.īreakpoint 2 at 0xc0115a45: file /home/vlad/ dev/tilck/ kernel/ char/tty/ term.c, line 709.Īt /home/vlad/ dev/tilck/ kernel/ char/tty/ term.c: 693Ħ93 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols) Īs you see, the whole QEMU VM is stuck until I quit GDB. The commands apparently don't get delivered to the remote side (QEMU), or they get delivered in a wrong way somehow. Term_action_ use_alt_ buffer (t=0xc017514c, use_alt_ buffer= true)Īt this point, I'm able to read the memory and the variables BUT, I cannot continue the execution, NOR doing any kind of step. Program received signal SIGTRAP, Trace/breakpoint trap. ![]() GDB detects the breakpoint, but in a weird way: Which seems (and actually is) a bad sign, for what comes later. > warning: Breakpoint address adjusted from 0xc01158fe to 0xffffffffc01158fe. With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead, something is broken. > at /home/vlad/ dev/tilck/ kernel/ char/tty/ term.c: 694Īnd then I was able to do `s`, `si` or `c`, exactly like with regular user applications. > Breakpoint 1, term_action_ use_alt_ buffer (t=0xc017514c, use_alt_ buffer= true) On my x86_64 machine with gdb version 'Ubuntu 8.1-0ubuntu3' I could happily debug any kernel running on a i386 qemu VM (qemu-system-i386) by just doing the following:Īnd then, when the breakpoint was hit I used to observe output like:
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |