From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63723 invoked by alias); 19 Apr 2016 06:26:19 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 63711 invoked by uid 89); 19 Apr 2016 06:26:18 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1390, H*Ad:D*ru X-HELO: mail-pa0-f51.google.com Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 19 Apr 2016 06:26:08 +0000 Received: by mail-pa0-f51.google.com with SMTP id zm5so3429041pac.0 for ; Mon, 18 Apr 2016 23:26:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=eShQ+Q1ZrP81zrB6Qz42O8CpN+rIujUusc5MH+xpU+w=; b=YCMrpyiaYukQQFZF4hh3qzLYoU2n1OAzFmf8Ht01VCyyBD3fSG29qewAxe/XrLkIHh i/NDvtjJZlJl/cytJLkqEkEVg53ITx6eVHF44fFbujM8gsxmm9HAJ3XRDRQtyRfX0vmo spGTt+fucerTdeWgFw49JyA5EVoVtfZDiwB8fK5amonmCsJa8hVazXvdI2PcvodclGSL YVfhWYXlOahrNA5teyT/OxWU13JLmbJvtnJuN2OW9YktBCcxzGzyEG6gGgsXOHJ4i2+h kyC9yprHdH1ZUvd6EMfV0dhAAGPvmm/1qAalJl2OoROgMZYhYe5JfUe+HTe1RbNz4pjo VJRA== X-Gm-Message-State: AOPr4FUuDySxU5L+gkpUEAMGYf6q2DYX1buFMDhzhrxJVWTcY/bqJ2AbGlYWKiF4ekshmmIn X-Received: by 10.66.148.35 with SMTP id tp3mr1657964pab.159.1461047166560; Mon, 18 Apr 2016 23:26:06 -0700 (PDT) Received: from linaro.org ([121.95.100.191]) by smtp.googlemail.com with ESMTPSA id y7sm87990830pfa.82.2016.04.18.23.26.02 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 18 Apr 2016 23:26:05 -0700 (PDT) Date: Tue, 19 Apr 2016 06:26:00 -0000 From: AKASHI Takahiro To: Michael Matz Cc: Alexander Monakov , Maxim Kuvyrkov , Li Bin , GCC Patches , Marcus Shawcroft , richard.earnshaw@arm.com, andrew.wafaa@arm.com, szabolcs.nagy@arm.com, masami.hiramatsu.pt@hitachi.com, geoff@infradead.org, guohanjun@huawei.com, felix.yang@huawei.com, jiangjiji@huawei.com Subject: Re: [PATCH] [AArch64] support -mfentry feature for arm64 Message-ID: <20160419062845.GC13600@linaro.org> References: <1457943260-30894-1-git-send-email-huawei.libin@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2016-04/txt/msg00898.txt.bz2 On Mon, Apr 18, 2016 at 02:12:09PM +0200, Michael Matz wrote: > 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. Yeah, this issue also trapped me before :) > 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. I don't get this idea very well. How can the instructions *before* a function label be executed after branching into this function? Thanks, -Takahiro AKASHI > > Ciao, > Michael. -- Thanks, -Takahiro AKASHI