From: Stafford Horne <shorne@gmail.com>
To: Sahil Siddiq <icegambit91@gmail.com>
Cc: Linux OpenRISC <linux-openrisc@vger.kernel.org>
Subject: Re: Queries regarding ftrace's implementation for OpenRISC-linux
Date: Tue, 6 May 2025 16:03:15 +0100 [thread overview]
Message-ID: <aBoks-Muf4CxQvhv@antec> (raw)
In-Reply-To: <e9f74ae6-10f3-4585-b727-928bb5749dd9@gmail.com>
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
next prev parent reply other threads:[~2025-05-06 15:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-03 16:14 Queries regarding ftrace's implementation for OpenRISC-linux Sahil Siddiq
2025-05-06 15:03 ` Stafford Horne [this message]
2025-05-08 18:40 ` Sahil Siddiq
2025-05-09 18:59 ` Stafford Horne
2025-05-10 8:18 ` Sahil Siddiq
2025-09-09 4:26 ` KProbes " Sahil Siddiq
2025-09-11 9:52 ` Stafford Horne
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aBoks-Muf4CxQvhv@antec \
--to=shorne@gmail.com \
--cc=icegambit91@gmail.com \
--cc=linux-openrisc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox