On 12/17/25 08:25, Patrick Rudolph wrote:
Currently FTRACE aborts on the first function call since getting the
timestamp causes a recursion and tracing is immediately disabled.
Fix that by adding 'notrace' to TSC timer functions.
TEST=The 'trace' cmd reports that functions have been traced on
qemu-q35 when CONFIG_TRACE is enabled and FTRACE=1.
Signed-off-by: Patrick Rudolph <[email protected]>
---
drivers/timer/tsc_timer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/timer/tsc_timer.c b/drivers/timer/tsc_timer.c
index dd16ab320b2..d17fb2337dc 100644
--- a/drivers/timer/tsc_timer.c
+++ b/drivers/timer/tsc_timer.c
@@ -395,14 +395,14 @@ void __udelay(unsigned long usec)
#endif
}
-static u64 tsc_timer_get_count(struct udevice *dev)
+static u64 notrace tsc_timer_get_count(struct udevice *dev)
{
u64 now_tick = rdtsc();
return now_tick - gd->arch.tsc_base;
}
-static void tsc_timer_ensure_setup(bool early)
+static void notrace tsc_timer_ensure_setup(bool early)
{
if (gd->arch.tsc_inited)
return;
Thank you for reporting your issues with the FTRACE functionality and
providing a fix for the x86 platform.
In __cyg_profile_func_enter() and __cyg_profile_func_exit() we call
add_ftrace().
In function add_ftrace() we call timer_get_us().
In drivers/timer/tsc_timer.c this function is marked notrace but not in
arch/arm/cpu/armv7/s5p-common/timer.c and not in arch/xtensa/lib/time.c.
The drivers/timer/tsc_timer.c implementation calls get_ticks() and
get_tbclk_mhz().
get_ticks() is marked notrace in lib/time.c but nowhere else.
get_ticks() in lib/time.c calls timer_get_count() implemented in
drivers/timer/timer-uclass.c which is marked notrace.
If CONFIG_TIMER_EARLY=y get_ticks() will call timer_early_get_count()
when the timer driver is not set-up yet.
Very few driver implementations of timer_get_count() are marked as
notrace (e.g. sandbox, risc-v).
Notrace function xtimer_early_get_rate() calls tsc_timer_ensure_setup().
My conclusion is that function tracing will fail on many more platforms
than only x86.
Reviewed-by: Heinrich Schuchardt <[email protected]>
