From: szabolcs.nagy@arm.com (Szabolcs Nagy)
To: linux-arm-kernel@lists.infradead.org
Subject: arm64:, Re: [RFC] Kernel livepatching support in GCC
Date: Fri, 23 Oct 2015 11:23:22 +0100 [thread overview]
Message-ID: <562A0A9A.6090102@arm.com> (raw)
In-Reply-To: <5629F9A7.3040808@linaro.org>
On 23/10/15 10:11, AKASHI Takahiro wrote:
> On 10/22/2015 07:26 PM, Szabolcs Nagy wrote:
>> On 22/10/15 11:14, AKASHI Takahiro wrote:
>>>
>>> I also have my own version of livepatch support for arm64 using yet-coming "-fprolog-add=N" option :)
>>> As we discussed before, the main difference will be how we should preserve LR register when invoking
>>> a ftrace hook (ftrace_regs_caller).
>>> But again, this is a topic to discuss mainly in linux-arm-kernel.
>>> (I have no intention of excluding gcc ml from the discussions.)
>>
>> is -fprolog-add=N enough from gcc?
>
> Yes, as far as I correctly understand this option.
>
>> i assume it solves the live patching, but i thought -mfentry
>> might be still necessary when live patching is not used.
>
> No.
> - Livepatch depends on ftrace's DYNAMIC_FTRACE_WITH_REGS feature
> - DYNAMIC_FTRACE_WITH_REGS can be implemented either with -fprolog-add=N or -mfentry
> - x86 is the only architecture that supports -mfentry AFAIK
> - and it is used in the kernel solely to implement this ftrace feature AFAIK
> - So once a generic option, fprolog-add=N, is supported, we have no reason to add arch-specific -mfentry.
>
>> or is the kernel fine with the current mcount abi for that?
>> (note that changes the code generation in leaf functions
>
> Can you please elaborate your comments in more details?
> I didn't get your point here.
>
ok, i may be confused.
i thought there is a static ftrace (functions are
instrumented with mcount using -pg) and a dynamic one
where the code is modified at runtime.
then i thought adding -fprolog-pad=N would be good for the
dynamic case, but not for the static case.
the static case may need improvements too because the
current way (using regular c call abi for mcount) affects
code generation more significantly than the proposed
-mfentry solution would (e.g. leaf functions turn into
non-leaf ones).
hence the question: is the kernel satisfied with -pg mcount
for the static ftrace or does it want -mfentry behaviour
instead?
prev parent reply other threads:[~2015-10-23 10:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <844CBBAF-DA0E-4164-9E35-34075A26F665@linaro.org>
[not found] ` <5628A738.5000305@huawei.com>
2015-10-22 10:14 ` arm64:, Re: [RFC] Kernel livepatching support in GCC AKASHI Takahiro
2015-10-22 10:26 ` Szabolcs Nagy
2015-10-23 9:11 ` AKASHI Takahiro
2015-10-23 10:23 ` Szabolcs Nagy [this message]
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=562A0A9A.6090102@arm.com \
--to=szabolcs.nagy@arm.com \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).