This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] [AArch64] support -mfentry feature for arm64
- From: AKASHI Takahiro <takahiro dot akashi at linaro dot org>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Andrew Pinski <pinskia at gmail dot com>, Maxim Kuvyrkov <maxim dot kuvyrkov at linaro dot org>, Li Bin <huawei dot libin at huawei dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>, Richard Earnshaw <richard dot earnshaw at arm dot com>, andrew dot wafaa at arm dot com, masami dot hiramatsu dot pt at hitachi dot com, geoff at infradead dot org, guohanjun at huawei dot com, "Yangfei (Felix)" <felix dot yang at huawei dot com>, jiangjiji at huawei dot com, nd at arm dot com
- Date: Tue, 19 Apr 2016 15:49:21 +0900
- Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64
- Authentication-results: sourceware.org; auth=none
- References: <1457943260-30894-1-git-send-email-huawei dot libin at huawei dot com> <B6E2AECD-096C-489F-A217-8140E781E722 at linaro dot org> <CA+=Sn1mQOeqZDRP-Yh8qWzbYiBOrMXZoJO7RqX2p6vELLZs3Vg at mail dot gmail dot com> <570FBE14 dot 10904 at arm dot com> <alpine dot LNX dot 2 dot 20 dot 1604181608580 dot 3543 at monopod dot intra dot ispras dot ru> <5714EF94 dot 1050101 at arm dot com> <alpine dot LNX dot 2 dot 20 dot 1604181821020 dot 3543 at monopod dot intra dot ispras dot ru>
On Mon, Apr 18, 2016 at 06:54:33PM +0300, Alexander Monakov wrote:
> On Mon, 18 Apr 2016, Szabolcs Nagy wrote:
> > On 18/04/16 14:26, Alexander Monakov wrote:
> > > On Thu, 14 Apr 2016, Szabolcs Nagy wrote:
> > >> looking at [2] i don't see why
> > >>
> > >> func:
> > >> mov x9, x30
> > >> bl _tracefunc
> > >> <function body>
> > >>
> > >> is not good for the kernel.
> > >>
> > >> mov x9, x30 is a nop at function entry, so in
> > >> theory 4 byte atomic write should be enough
> > >> to enable/disable tracing.
> > >
> > > Overwriting x9 can be problematic because GCC has gained the ability to track
> > > register usage interprocedurally: if foo() calls bar(), and GCC has already
> > > emitted code for bar() and knows that it cannot change x9, it can use that
> > > knowledge to avoid saving/restoring x9 in foo() around calls to bar(). See
> > > option '-fipa-ra'.
> > >
> > > If there's no register that can be safely used in place of x9 here, then
> > > the backend should emit the entry/pad appropriately (e.g. with an unspec that
> > > clobbers the possibly-overwritten register).
> > >
> >
> > (1) nop padded function can be assumed to clobber all temp regs
>
> This may be undesirable if the nop pad is expected to be left untouched
> most of the time, because it would penalize the common case. If only
> sufficiently complex functions (e.g. making other calls anyway) are expected
> to be padded, it's moot.
Almost of all the "C" functions in the kernel will be compiled
with -mfentry, and later on, we can dynamically turn on and off
tracing per-function.
> > (2) or _tracefunc must save/restore all temp regs, not just arg regs.
>
> This doesn't work: when _tracefunc starts executing, old value of x9 is
> already unrecoverable.
Yeah. We may, instead, be able to preserve LR value on a stack,
but obviously with performance penalty.
I wondered whether we could stop "instruction scheduling" partially,
and always generate a fixed sequence of instructions like
save x29, x30, [sp, #-XX]!
mov x29, x30
bl _mcount
<function body>
but Maxim said no :)
Thanks,
-Takahiro AKASHI
> > on x86_64, glibc and linux _mcount and __fentry__ don't
> > save %r11 (temp reg), only the arg regs, so i think nop
> > padding should behave the same way (1).
>
> That makes sense (modulo what I said above about penalizing tiny functions).
>
> Heh, I started wondering if on x86 this is handled correctly when the calls
> are nopped out, and it turns out -pg disables -fipa-ra (in toplev.c)! :)
>
> Alexander
--
Thanks,
-Takahiro AKASHI