Re: Adding ftrace support for coldfire ?

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 18 Oct 2024 16:37:39 +0200
Jean-Michel Hautbois <jeanmichel.hautbois@yoseli.org> wrote:

> Hi there !
> 
> I always have been a fan of ftrace, in particular when it comes to 
> latency issues debugging.
> 
> I would love to use it on my coldfire custom board (M54418 based).
> I can see that it needs TRACE_IRQFLAGS_SUPPORT and STACKTRACE_SUPPORT, 
> both are missing.
> 
> Is it not doable ? If it is, what is required ? Implementing the 
> save_stack_trace() ? I suppose it is not enough :-) ?
> 
> Thanks in advance, as it would be a great helper !
> 

The TRACE_IRQFLAGS_SUPPORT requires the architecture to call
trace_hardirqs_off() when interrupts are disabled and trace_hardirqs_on()
when they are enabled. Now this is mostly done for you when you use the
function local_irq_save() and local_irq_restore() and friends from C code.

But each architecture needs to add those calls in the assembly for when
that happens, or even in C code where interrupts are being enabled or
disabled by other functions than generic code.

Now, x86 has been updated to basically enable interrupts almost immediately
when coming back into the kernel from a system call. Also the irq_enter()
and irq_exit() routines handle this for you too. Today x86 doesn't even call
trace_hardirqs_on/off() anywhere, but still supports TRACE_IRQFLAGS. It may
be possible that your architecture already supports TRACE_IRQFLAGS.

Basically, it is a requirement to use lockdep properly. If you enable
TRACE_IRQFLAGS_SUPPORT and enable lockdep, it will give you nasty warnings
if the architecture isn't keeping the irqflags in sync with the tracer. 

As for STACKTRACE_SUPPORT, you just need to implement save_stack_trace() or
arch_stack_walk() (which would be needed for live kernel patching). See the
code in kernel/stacktrace.c.

-- Steve