Queries regarding ftrace's implementation for OpenRISC-linux

Queries regarding ftrace's implementation for OpenRISC-linux

[Sahil Siddiq]

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.

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).

Also, or1k-linux-gcc (version 13.3.0) does not support the -mfentry flag. So, if fentry
is to be supported for OpenRISC, this will also involve changes in GCC and glibc.

Thanks,
Sahil

[1] https://www.kernel.org/doc/html/latest/trace/ftrace-design.html
[2] https://web.archive.org/web/20250215201110/https://www.linuxjournal.com/content/simplifying-function-tracing-modern-gcc

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

[Stafford Horne]

Hi Sahil,

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.

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.

[1] https://docs.kernel.org/livepatch/livepatch.html#kprobes-ftrace-livepatching
[2] https://docs.kernel.org/staging/static-keys.html

-Stafford

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

[Sahil Siddiq]

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?

Thanks,
Sahil

[1] https://patchwork.kernel.org/project/linux-kbuild/cover/cover.thread-aa7b8d.your-ad-here.call-01533557518-ext-9465@work.hours/
[2] https://lwn.net/ml/linux-kernel/20230511093234.3123181-1-suagrfillet@gmail.com/

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

[Stafford Horne]

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

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

[Sahil Siddiq]

Hi,

On 5/10/25 12:29 AM, Stafford Horne wrote:
> 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.
> 

Sure. Based on what I have understood from the synopsis of the GSoC proposal [1],
the focus will initially be on jump_labels. So, I'll start going through kprobes
in the meantime.

Thanks,
Sahil

[1] https://summerofcode.withgoogle.com/programs/2025/projects/qYsJ8YEg

KProbes for OpenRISC-linux

[Sahil Siddiq]

Hi,

On 5/10/25 1:48 PM, Sahil Siddiq wrote:
> Sure. Based on what I have understood from the synopsis of the GSoC proposal [1],
> the focus will initially be on jump_labels. So, I'll start going through kprobes
> in the meantime.
I am writing this email to let you know that I am still interested in implementing
KProbes for OpenRISC-Linux. My changes make use of Miao's text patching implementation.
I should be able to send a patch soon.

Thanks,
Sahil

Re: KProbes for OpenRISC-linux

[Stafford Horne]

On Tue, Sep 09, 2025 at 09:56:06AM +0530, Sahil Siddiq wrote:
> Hi,
> 
> On 5/10/25 1:48 PM, Sahil Siddiq wrote:
> > Sure. Based on what I have understood from the synopsis of the GSoC proposal [1],
> > the focus will initially be on jump_labels. So, I'll start going through kprobes
> > in the meantime.
> I am writing this email to let you know that I am still interested in implementing
> KProbes for OpenRISC-Linux. My changes make use of Miao's text patching implementation.
> I should be able to send a patch soon.

Good news, we are looking forward to it.

-Stafford