Re: Queries regarding ftrace's implementation for OpenRISC-linux

[Stafford Horne <shorne@gmail.com>]

On Fri, May 09, 2025 at 12:10:57AM +0530, Sahil Siddiq wrote:
> Hi Stafford,
> 
> Thank you for your response.
> 
> On 5/6/25 8:33 PM, Stafford Horne wrote:
> > On Sat, May 03, 2025 at 09:44:54PM +0530, Sahil Siddiq wrote:
> > > Hi,
> > > 
> > > I have been looking into implementing ftrace for OpenRISC-linux. Based on what I have
> > > understood from the ftrace design document [1], mcount will have to be implemented in
> > > the kernel for ftrace to work.
> > 
> > Thats right.
> > 
> > > While this document is outdated, I did come across an article in the Linux Journal [2]
> > > that explains the use of fentry instead of mcount in the implementation of ftrace. It
> > > states that fentry is a powerful alternative to mcount. To make use of fentry, GCC's
> > > -pg flag needs to be used along with the -mfentry flag. Simply calling -pg results in
> > > mcount being used.
> > > 
> > > Should it be possible for ftrace to make use of either option (fentry and mcount) when
> > > implementing it for OpenRISC? Or should it only use fentry (or mcount)? mcount still
> > > seems to be used in other architectures (I have only checked MIPS, RISC-V, LoongArch
> > > and ARM so far).
> > 
> > I think we should stick to mcount for now.  As I understand fentry is mainly and x86
> > feature now.  We should be able to get it done with mcount, as you say that is
> > what is what is used by other architectures like riscv.
> 
> Going ahead with mcount would be relatively simpler especially since mcount is already
> supported in OpenRISC. I must point out, though, that I overlooked the following
> developments that have been made for other architectures:
> 
> 1. Ftrace with fentry for s390. [1]
> 2. Optimizing function trace for RISC-V. [2]
> 
> > Another point is that for ftrace to work it uses a kind live patching [1] to turn
> > the mcount calls to NOPs when the kernel boots up.  Then when we turn on tracing
> > the code is patched to enable the mcount call.
> > 
> > This live patching covers:
> > 
> >   - kprobes - adds single instruction break points into kernel code
> >   - static keys - allows for static branches, i.e. the check for cache enabled can
> >     be done once then code re-written to to make certain checks go away.  We
> >     could use this for cache availability checks.
> >   - jump_label - low level support for code patching
> > 
> > I think before going to far with ftrace we should look more into OpenRISC's
> > roadmap for all of these.
> 
> Understood. As a first step, I think it should be possible to support some of the
> features in the debug subsystem - k(ret)probes, u(ret)probes, optprobes. Jump_labels
> and perf-related features (e.g. kprobes-event) can be built on top of them.
> 
> What are your thoughts on this?

I think its good, we should start working on this.  Also, there is another
person who is interested in working on these features.  I will ask him to reply
on this with his thoughts and see if there is a way we can split up the work.

But please start your progress as you can.

-Stafford