Hi Heinrich, On Sat, 20 Dec 2025 at 18:59, Heinrich Schuchardt <[email protected]> wrote: > > In the current state the trace functionality is not usable. > With CONFIG_TRACE=y not even QEMU can boot. > > With this series CONFIG_TRACE becomes usable on > qemu-riscv64_smode_defconfig.
I would be great to enable this feature on QEMU! > > It all starts with correcting the handling of recursive calls > to the measuring functions at the entry and exit points. > > When a function is entered we record the time and reading the > timer leads to a recursion which should not switch of recording off > traces but just be ignored. See my comment on the patch. > > The meminfo patches are in the series because the output > of the meminfo command depends on CONFIG_TRACE. > > Also the Pythontrace test does not consider that output depends on > configuration. > > There are still issues with qemu-x86_64_defconfig when trying to > trace. But I would like to collect early feedback. We have sandbox tests for tracing, so eventually I suppose this could be added to CI. > > Thanks to Patrick Rudolph for pointing to his issues with tracing. > > Heinrich Schuchardt (8): > trace: correct handling of recursive call > trace: initr_trace must succeed initr_dm > test: test_trace: remove invalid assert > trace: increase TRACE_CALL_DEPTH_LIMIT > cmd/meminfo: display of addresses above 4 GiB > test: cmd: consider configuration in meminfo test > test: initf_malloc is only traced with EARLY_TRACE > test: clean up test_trace.py code > > cmd/meminfo.c | 8 ++--- > common/board_r.c | 2 +- > lib/Kconfig | 2 +- > lib/trace.c | 59 +++++++++++++++++-------------------- > test/cmd/meminfo.c | 20 +++++++++---- > test/py/tests/test_trace.py | 52 +++++++++++++------------------- > 6 files changed, 68 insertions(+), 75 deletions(-) > > -- > 2.51.0 > Regards, Simon
