OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

docs/system: clarify limits of using gdbstub in system emulation

Browse Source 
It seems some users will try and use the gdbstub to debug userspace
inside a system emulation. While possible clarify the limitations of
this approach and direct the users to a less head scratching way of
debugging user-space.

Clarifies: https://gitlab.com/qemu-project/qemu/-/issues/1274
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Message-Id: <20231120150833.2552739-9-alex.bennee@linaro.org>
This commit is contained in:
Alex Bennée 2023-11-20 15:08:27 +00:00
parent ef073ebd32
commit 84dd7d88c9
1 changed files with 12 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/system/gdb.rst
View File

@ -60,7 +60,7 @@ As TCG cannot track all memory accesses in user-mode there is no
support for watchpoints.
Relocating code
---------------
===============
On modern kernels confusion can be caused by code being relocated by
features such as address space layout randomisation. To avoid
@ -68,6 +68,17 @@ confusion when debugging such things you either need to update gdb's
view of where things are in memory or perhaps more trivially disable
ASLR when booting the system.
Debugging user-space in system emulation
========================================
While it is technically possible to debug a user-space program running
inside a system image, it does present challenges. Kernel preemption
and execution mode changes between kernel and user mode can make it
hard to follow what's going on. Unless you are specifically trying to
debug some interaction between kernel and user-space you are better
off running your guest program with gdb either in the guest or using
a gdbserver exposed via a port to the outside world.
Debugging multicore machines
============================