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

[Sahil Siddiq <icegambit91@gmail.com>]

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