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: Ramana Radhakrishnan <ramana dot gcc at googlemail dot com>
- 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, Takahiro Akashi <takahiro dot akashi at linaro dot org>, guohanjun at huawei dot com, "Yangfei (Felix)" <felix dot yang at huawei dot com>, jiangjiji at huawei dot com, nd <nd at arm dot com>
- Date: Mon, 18 Apr 2016 14:33:45 +0100
- 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>
On Mon, Apr 18, 2016 at 2:26 PM, Alexander Monakov <amonakov@ispras.ru> 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).
Can you not use one of x16 / x17 the intra-procedure-call scratch
registers as per the PCS ?
regards
Ramana
>
> Or, with Michael Matz' suggestion, there can be one nop at function start and
> a big enough pad just before the function, and that pad can just push/pop x30
> on its own.
>
> Alexander