diff options
| author | Alex Bennée <alex.bennee@linaro.org> | 2023-11-20 15:08:27 +0000 |
|---|---|---|
| committer | Alex Bennée <alex.bennee@linaro.org> | 2023-11-23 14:10:06 +0000 |
| commit | 84dd7d88c98831f1ef95262990ea185a36c79fa1 (patch) | |
| tree | 7ca86215a078d280778a877e7f106fe5ca7ed516 /docs/system | |
| parent | ef073ebd329aecc5f31a3a9d6e355e367f5bfb99 (diff) | |
| download | qemu-84dd7d88c98831f1ef95262990ea185a36c79fa1.zip qemu-84dd7d88c98831f1ef95262990ea185a36c79fa1.tar.gz qemu-84dd7d88c98831f1ef95262990ea185a36c79fa1.tar.bz2 | |
docs/system: clarify limits of using gdbstub in system emulation
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>
Diffstat (limited to 'docs/system')
| -rw-r--r-- | docs/system/gdb.rst | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/docs/system/gdb.rst b/docs/system/gdb.rst index 9906991..4228cb5 100644 --- a/docs/system/gdb.rst +++ b/docs/system/gdb.rst @@ -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 ============================ |