Public bug reported:
Hi,
On my x86_64 machine [running Ubuntu 18.04.3 LTS] 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:
> target remote localhost:1234
> b term.c:694
and then, when the breakpoint was hit I used to observe output like:
> Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c <first_instance>,
> use_alt_buffer=true)
> at /home/vlad/dev/tilck/kernel/char/tty/term.c:694
And then I was able to do `s`, `si` or `c`, exactly like with regular
user applications.
With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead,
something is broken.
By doing the same things I observe:
> (gdb) b term.c:693
> warning: Breakpoint address adjusted from 0xc01158fe to 0xffffffffc01158fe.
Which seems (and actually is) a bad sign, for what comes later. [why do
you need to change the address? why do you want to extend it to 64-bit
for a 32-bit machine?? mmm..]
GDB detects the breakpoint, but in a weird way:
Program received signal SIGTRAP, Trace/breakpoint trap.
term_action_use_alt_buffer (t=0xc017514c <first_instance>, use_alt_buffer=true)
At this point, I'm able to read the memory and the variables BUT, I
cannot continue the execution, NOR doing any kind of step. The commands
apparently don't get delivered to the remote side (QEMU), or they get
delivered in a wrong way somehow. Example output:
(gdb) b 709
warning: Breakpoint address adjusted from 0xc0115a45 to 0xffffffffc0115a45.
Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c,
line 709.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
term_action_use_alt_buffer (t=0xc017514c <first_instance>, use_alt_buffer=true)
at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols);
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
term_action_use_alt_buffer (t=0xc017514c <first_instance>, use_alt_buffer=true)
at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols);
(gdb) c
Continuing.
As you see, the whole QEMU VM is stuck until I quit GDB.
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. 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. It's totally independent from that.
Final remark: note that I'm running gdb on x86_64 machine, while I'm
debugging a kernel running on a i386 (virtual) machine. 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).
Thanks a lot,
Vlad
** Affects: gdb (Ubuntu)
Importance: Undecided
Status: New
** Tags: bionic regression-update
** Description changed:
Hi,
On my x86_64 machine [running Ubuntu 18.04.3 LTS] 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:
> target remote localhost:1234
> b term.c:694
and then, when the breakpoint was hit I used to observe output like:
> Breakpoint 1, term_action_use_alt_buffer (t=0xc017514c <first_instance>,
use_alt_buffer=true)
> at /home/vlad/dev/tilck/kernel/char/tty/term.c:694
And then I was able to do `s`, `si` or `c`, exactly like with regular
user applications.
With the newest update of gdb, version 'Ubuntu 8.1-0ubuntu3.1', instead,
something is broken.
By doing the same things I observe:
> (gdb) b term.c:693
> warning: Breakpoint address adjusted from 0xc01158fe to 0xffffffffc01158fe.
- Which seems (and actually is a bad sign), for what comes later. [why do
+ Which seems (and actually is) a bad sign, for what comes later. [why do
you need to change the address? why do you want to extend it to 64-bit
for a 32-bit machine?? mmm..]
GDB detects the breakpoint, but in a weird way:
Program received signal SIGTRAP, Trace/breakpoint trap.
term_action_use_alt_buffer (t=0xc017514c <first_instance>,
use_alt_buffer=true)
At this point, I'm able to read the memory and the variables BUT, I
cannot continue the execution, NOR doing any kind of step. The commands
apparently don't get delivered to the remote side (QEMU), or they get
delivered in a wrong way somehow. Example output:
(gdb) b 709
warning: Breakpoint address adjusted from 0xc0115a45 to 0xffffffffc0115a45.
Breakpoint 2 at 0xc0115a45: file /home/vlad/dev/tilck/kernel/char/tty/term.c,
line 709.
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
term_action_use_alt_buffer (t=0xc017514c <first_instance>,
use_alt_buffer=true)
- at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
+ at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols);
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
term_action_use_alt_buffer (t=0xc017514c <first_instance>,
use_alt_buffer=true)
- at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
+ at /home/vlad/dev/tilck/kernel/char/tty/term.c:693
693 t->alt_buf = kmalloc(sizeof(u16) * t->rows * t->cols);
(gdb) c
Continuing.
As you see, the whole QEMU VM is stuck until I quit GDB.
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. 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. It's totally independent from that.
Final remark: note that I'm running gdb on x86_64 machine, while I'm
debugging a kernel running on a i386 (virtual) machine. 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).
Thanks a lot,
Vlad
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1846557
Title:
Unable to debug any kernel on i386 qemu machine
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1846557/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
