Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp1230396pxb; Sat, 9 Jan 2021 12:04:07 -0800 (PST) X-Google-Smtp-Source: ABdhPJyTSLOt2iNJIajxenNvIQT7NVPgnH4kfn+da/KHkK9cnANuK7cUKeR8dxfdxOwVESA6MxYa X-Received: by 2002:a17:906:9613:: with SMTP id s19mr6369485ejx.351.1610222647648; Sat, 09 Jan 2021 12:04:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610222647; cv=none; d=google.com; s=arc-20160816; b=DODczaPLfIgpt38s4OLOd6AN7juUEBzooKJvOjNmhwA3EdYIy7pk+VGxIFnhbW8CTu 3jjG62YmmhV1HdLzSK/stio5c3HMe6kd2KWsCm33P5W+R5gALf7HniQMgDHW1e1OKOfm yEY+fuE/z0Z4JhD03oF/UYaB2M1qhUQ+xwtPWyENzNd1UYEzSXbA1DzhEY+5NUuNVOX5 0HAg2yiUyrp/cAerzJPQTCF6+CqbxFxc77o4jyCm0luq1d51TXWxa4OHiW9A7gblJ6Y/ r/YSey13a/Mf5GhX7XkO125HmxIQ3SJVD/I9yLWoD2nmhOyFku85iomaORjVtwQbHM3g cXQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:message-id:in-reply-to :subject:cc:to:from:date; bh=/wZLi0UuNls+XFYjsBHV85gjRUW1BrqHsXnyW9oidmQ=; b=cEJhuRs3Vxc/yqhd9tllsdaPPRkdui7AakzLrAOT0nOlTNYSH/EqwASakl09/B8zzQ ZNYWBhLQWcTVMdqR/AIY3WlLthdhTcbsae82KlvRNmausaD5AiU51AkY0ktzvKNy1TFF Ug1cMBJziYVmMdRy3fNvTr+nIJqksZwChN0zt+rTLmxUz2f2BavmZzvQuruqO5o46hyN ZrKpU/QjMPhghkO0Bfc6EIaB5sp2QonQu+zHtmqujMulTsiVPl/sjc6O0+kme8ZCUVGy xgZKKCH9JvJg6q+sjtBs4aa2Vh4i0zpGo3w9gMWPpDebgxFNEwSdjuu8yQ6odTmFF4WQ ydcg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p31si5644157edd.471.2021.01.09.12.03.42; Sat, 09 Jan 2021 12:04:07 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726080AbhAIUCu (ORCPT + 99 others); Sat, 9 Jan 2021 15:02:50 -0500 Received: from [78.8.192.131] ([78.8.192.131]:12716 "EHLO orcam.me.uk" rhost-flags-FAIL-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1725999AbhAIUCu (ORCPT ); Sat, 9 Jan 2021 15:02:50 -0500 X-Greylist: delayed 504 seconds by postgrey-1.27 at vger.kernel.org; Sat, 09 Jan 2021 15:02:49 EST Received: from cvs.linux-mips.org (eddie.linux-mips.org [148.251.95.138]) by orcam.me.uk (Postfix) with ESMTPS id D7E412BE0EC; Sat, 9 Jan 2021 19:53:52 +0000 (GMT) Date: Sat, 9 Jan 2021 19:53:19 +0000 (GMT) From: "Maciej W. Rozycki" To: Aurelien Jarno cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, YunQiang Su , Thomas Bogendoerfer , Huacai Chen , Jiaxun Yang , "open list:MIPS" Subject: Re: [PATCH] MIPS: Support binutils configured with --enable-mips-fix-loongson3-llsc=yes In-Reply-To: <20210109193048.478339-1-aurelien@aurel32.net> Message-ID: References: <20210109193048.478339-1-aurelien@aurel32.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 9 Jan 2021, Aurelien Jarno wrote: > diff --git a/arch/mips/Makefile b/arch/mips/Makefile > index cd4343edeb11..5ffdd67093bc 100644 > --- a/arch/mips/Makefile > +++ b/arch/mips/Makefile > @@ -136,6 +136,25 @@ cflags-$(CONFIG_SB1XXX_CORELIS) += $(call cc-option,-mno-sched-prolog) \ > # > cflags-y += -fno-stack-check > > +# binutils from v2.35 when built with --enable-mips-fix-loongson3-llsc=yes, > +# supports an -mfix-loongson3-llsc flag which emits a sync prior to each ll > +# instruction to work around a CPU bug (see __SYNC_loongson3_war in asm/sync.h > +# for a description). > +# > +# We disable this in order to prevent the assembler meddling with the > +# instruction that labels refer to, ie. if we label an ll instruction: > +# > +# 1: ll v0, 0(a0) > +# > +# ...then with the assembler fix applied the label may actually point at a sync > +# instruction inserted by the assembler, and if we were using the label in an > +# exception table the table would no longer contain the address of the ll > +# instruction. Interesting. Given that a MIPS assembler is generally free to shuffle instructions as it sees fit in its default reorder mode as long as that does not change the semantics of the code executed, shouldn't we instead place all label/instruction pairs used for exception handling in noreorder blocks so as to make sure the label refers to the instruction an exception handler expects it to? E.g. for the case quoted above: .set push .set noreorder 1: ll v0, 0(a0) .set pop Maciej