fdeccf932d
In order to facilitate the reorganization of qemu-doc.texi content, as well as the conversion to rST/Sphinx, split it in multiple .texi files that are included from docs/system. The "other devices" section is renamed to ivshmem and placed last. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Alex Bennée <alex.bennee@linaro.org> Tested-by: Alex Bennée <alex.bennee@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Message-id: 20200228153619.9906-6-peter.maydell@linaro.org Message-id: 20200226113034.6741-6-pbonzini@redhat.com Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
72 lines
2.5 KiB
Plaintext
72 lines
2.5 KiB
Plaintext
@node gdb_usage
|
|
@section GDB usage
|
|
|
|
QEMU has a primitive support to work with gdb, so that you can do
|
|
'Ctrl-C' while the virtual machine is running and inspect its state.
|
|
|
|
In order to use gdb, launch QEMU with the '-s' option. It will wait for a
|
|
gdb connection:
|
|
@example
|
|
@value{qemu_system} -s -kernel bzImage -hda rootdisk.img -append "root=/dev/hda"
|
|
Connected to host network interface: tun0
|
|
Waiting gdb connection on port 1234
|
|
@end example
|
|
|
|
Then launch gdb on the 'vmlinux' executable:
|
|
@example
|
|
> gdb vmlinux
|
|
@end example
|
|
|
|
In gdb, connect to QEMU:
|
|
@example
|
|
(gdb) target remote localhost:1234
|
|
@end example
|
|
|
|
Then you can use gdb normally. For example, type 'c' to launch the kernel:
|
|
@example
|
|
(gdb) c
|
|
@end example
|
|
|
|
Here are some useful tips in order to use gdb on system code:
|
|
|
|
@enumerate
|
|
@item
|
|
Use @code{info reg} to display all the CPU registers.
|
|
@item
|
|
Use @code{x/10i $eip} to display the code at the PC position.
|
|
@item
|
|
Use @code{set architecture i8086} to dump 16 bit code. Then use
|
|
@code{x/10i $cs*16+$eip} to dump the code at the PC position.
|
|
@end enumerate
|
|
|
|
Advanced debugging options:
|
|
|
|
The default single stepping behavior is step with the IRQs and timer service routines off. It is set this way because when gdb executes a single step it expects to advance beyond the current instruction. With the IRQs and timer service routines on, a single step might jump into the one of the interrupt or exception vectors instead of executing the current instruction. This means you may hit the same breakpoint a number of times before executing the instruction gdb wants to have executed. Because there are rare circumstances where you want to single step into an interrupt vector the behavior can be controlled from GDB. There are three commands you can query and set the single step behavior:
|
|
@table @code
|
|
@item maintenance packet qqemu.sstepbits
|
|
|
|
This will display the MASK bits used to control the single stepping IE:
|
|
@example
|
|
(gdb) maintenance packet qqemu.sstepbits
|
|
sending: "qqemu.sstepbits"
|
|
received: "ENABLE=1,NOIRQ=2,NOTIMER=4"
|
|
@end example
|
|
@item maintenance packet qqemu.sstep
|
|
|
|
This will display the current value of the mask used when single stepping IE:
|
|
@example
|
|
(gdb) maintenance packet qqemu.sstep
|
|
sending: "qqemu.sstep"
|
|
received: "0x7"
|
|
@end example
|
|
@item maintenance packet Qqemu.sstep=HEX_VALUE
|
|
|
|
This will change the single step mask, so if wanted to enable IRQs on the single step, but not timers, you would use:
|
|
@example
|
|
(gdb) maintenance packet Qqemu.sstep=0x5
|
|
sending: "qemu.sstep=0x5"
|
|
received: "OK"
|
|
@end example
|
|
@end table
|
|
|