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: Michael Matz <matz at suse dot de>
- To: Alexander Monakov <amonakov at ispras dot ru>
- Cc: 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 dot earnshaw at arm dot com, andrew dot wafaa at arm dot com, szabolcs dot nagy at arm dot com, masami dot hiramatsu dot pt at hitachi dot com, geoff at infradead dot org, takahiro dot akashi at linaro dot org, guohanjun at huawei dot com, felix dot yang at huawei dot com, jiangjiji at huawei dot com
- Date: Mon, 18 Apr 2016 14:12:09 +0200 (CEST)
- 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> <alpine dot LSU dot 2 dot 20 dot 1604151739210 dot 20277 at wotan dot suse dot de> <alpine dot LNX dot 2 dot 20 dot 1604152026570 dot 26109 at monopod dot intra dot ispras dot ru> <alpine dot LNX dot 2 dot 20 dot 1604171752300 dot 26109 at monopod dot intra dot ispras dot ru>
Hi,
On Sun, 17 Apr 2016, Alexander Monakov wrote:
> I've noticed an issue in my (and probably Michael's) solution: if
> there's a thread that made it past the first nop, but is still executing
> the nop pad, it's unsafe to replace the nops. To solve that, it
> suffices to have a forward branch in place of the first nop to begin
> with (i.e. have the compiler emit it).
True. I wonder if the generic solution in GCC should do that always or if
the patch infrastructure should do that to enable more freedom like doing
this:
> But if Szabolcs' two-instruction
> sequence in the adjacent subthread is sufficient, this is moot.
. It can also be solved by having just one NOP after the function label,
and a number of them before, then no thread can be in the nop pad. That
seems to indicate that GCC should not try to be too clever and simply
leave the specified number of nops before and after the function label,
leaving safety measures to the patching infrastructure.
Ciao,
Michael.