From bde13c37721d563798aac587e9ce91126554c7ca Mon Sep 17 00:00:00 2001 From: Ciro Santilli Date: Wed, 2 May 2018 17:07:39 +0100 Subject: [PATCH] readme: qemu failed interesting multicore debug attempt qemu cannot trace memory accesses --- README.adoc | 20 +++++++++++++++++++- 1 file changed, 19 insertions(+), 1 deletion(-) diff --git a/README.adoc b/README.adoc index 04ae97e..11c3b2a 100644 --- a/README.adoc +++ b/README.adoc @@ -1399,6 +1399,18 @@ on many (all?) functions. See also: https://github.com/cirosantilli/linux-kernel-module-cheat/issues/19 +=== GDB step debug multicore + +https://stackoverflow.com/questions/42800801/how-to-use-gdb-to-debug-qemu-with-smp-symmetric-multiple-processors + +Modify the number of cores: <> + +TODO: how to do something cool to see that in action? + +I tried to play around with `taskset`, but when I have two CPUs the <> don't work... Why? + +We should also try it out with kernel modules: https://stackoverflow.com/questions/28347876/set-cpu-affinity-on-a-loadable-linux-kernel-module + == KGDB TODO: only working with <>. Without it, nothing shows on the terminal. So likely something linked to the option `console=ttyS0`. @@ -3535,7 +3547,13 @@ just appears to output both cores intertwined without any clear differentiation. TODO: is is possible to show which instructions ran at each point in time, in addition to the address of the instruction with `exec_tb` shows? Hopefully dissembled, not just the instruction memory. -PANDA can list memory addresses, so I bet it can also decode the instructions: https://github.com/panda-re/panda/blob/883c85fa35f35e84a323ed3d464ff40030f06bd6/panda/docs/LINE_Censorship.md I wonder why they don't just upstream those things to QEMU's tracing. +PANDA can list memory addresses, so I bet it can also decode the instructions: https://github.com/panda-re/panda/blob/883c85fa35f35e84a323ed3d464ff40030f06bd6/panda/docs/LINE_Censorship.md I wonder why they don't just upstream those things to QEMU's tracing: https://github.com/panda-re/panda/issues/290 + +Memory access on vanilla seem impossible due to optimizations that QEMU does: + +* https://lists.gnu.org/archive/html/qemu-devel/2015-06/msg07479.html +* https://lists.gnu.org/archive/html/qemu-devel/2014-04/msg02856.html +* https://lists.gnu.org/archive/html/qemu-devel/2012-08/msg03057.html ==== gem5 tracing