docs/system/gdb.rst

7 (the "gdbstub"). This allows you to debug guest code in the same
8 way that you might with a low-level debug facility like JTAG
9 on real hardware. You can stop and start the virtual machine,
16 guest until you tell it to from gdb. (If you want to specify which
35 Then you can use gdb normally. For example, type 'c' to launch the
67 confusion when debugging such things you either need to update gdb's
77 hard to follow what's going on. Unless you are specifically trying to
78 debug some interaction between kernel and user-space you are better
97 When you connect gdb to the gdbstub, it will automatically
98 connect to the first inferior; you can display the CPUs in this
103 handle multiple inferiors, and so you have to explicitly connect
104 to them. First, you must connect with the ``extended-remote``
110 first cluster. You need to create inferiors for the other
123 Once you've done this, ``info threads`` will show CPUs in
124 all the clusters you have attached to::
131 You probably also want to set gdb to ``schedule-multiple`` mode,
132 so that when you tell gdb to ``continue`` it resumes all CPUs,
133 not just those in the cluster you are currently working on::
142 running several tests in parallel, or if you do not have a known free TCP
157 Note that to use a unix socket for the connection you will need
171 current instruction. This means you may hit the same breakpoint a number
173 Because there are rare circumstances where you want to single step into
175 three commands you can query and set the single step behavior:
199    the single step, but not timers, you would use:
214 If you want to examine/change the physical memory you can set the gdbstub
220     This will return either 0 or 1, 1 indicates you are currently in the