All of lore.kernel.org
 help / color / mirror / Atom feed
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?

      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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.