From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 409D3C433E0 for ; Sat, 13 Feb 2021 11:02:26 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 00BE464DD9 for ; Sat, 13 Feb 2021 11:02:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229671AbhBMLCJ (ORCPT ); Sat, 13 Feb 2021 06:02:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:53310 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229512AbhBMLCE (ORCPT ); Sat, 13 Feb 2021 06:02:04 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id F41FC64E44 for ; Sat, 13 Feb 2021 11:01:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613214083; bh=G71u7RTd4A+rBB1I9GNDIIEuu107tc6tTr/aifGEocg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GxERvQ0VZIYnBHwi/rOGp9DB578dL+KH+k7p8P662CGeWvdboRzfuzLuCr5sfmEgv kWmT5MswkYSl2Ws4Xctgd6mpy4+2ilQmFBOa/qXQc0Rl2CSLsZ/Fccvyp5/Uu1+rj/ 3rFHXqglXncFU7yoMyYc2JGJvuiWjwIT19EuRqCkFUyxmlvLTdgIBUZg7VWIMLPefh VitmMS4egfS7kwjcsF4QMuMoxuMv9NeLnnwQMQlIqBDQyhnczuu/z/oKzFj+kT1n7/ KqzCF1E4Wir/qJY2512e6WhkcrgPJLew/1xm+YnimDrPJbfAMwH9RDIkbzOZqhq52l yzv3X8rb4uo1g== Received: by mail-ot1-f49.google.com with SMTP id y11so1720957otq.1 for ; Sat, 13 Feb 2021 03:01:22 -0800 (PST) X-Gm-Message-State: AOAM5317hk0LW2Uwe/gHstOtleq6CgRvDB8WkRRcOzoakBm+0xxGNTFZ 0ilLqVeXsNN+/QthyqNKc2A2aKt4i2Zd/sLCnU8= X-Google-Smtp-Source: ABdhPJwbPg/JYsOrKxV0akZHoER+jZQufik0pH+YRE9RS6ub2wS5g0Dx/2q5znjGky9VctmOud4xL7YUR21sYDAMGVU= X-Received: by 2002:a05:6830:13ce:: with SMTP id e14mr4959394otq.108.1613214082190; Sat, 13 Feb 2021 03:01:22 -0800 (PST) MIME-Version: 1.0 References: <20210128193422.241155-1-ndesaulniers@google.com> In-Reply-To: From: Ard Biesheuvel Date: Sat, 13 Feb 2021 12:01:10 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL To: Arnd Bergmann Cc: Nick Desaulniers , Russell King , Arnd Bergmann , Nathan Chancellor , Linux ARM , Linux Kernel Mailing List , clang-built-linux Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 29 Jan 2021 at 00:30, Ard Biesheuvel wrote: > > On Thu, 28 Jan 2021 at 23:28, Arnd Bergmann wrote: > > > > On Thu, Jan 28, 2021 at 10:03 PM Ard Biesheuvel wrote: > > > On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers wrote: > > > > @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void) > > > > > > > > TEST_UNSUPPORTED("strexb r0, r1, [r2]") > > > > TEST_UNSUPPORTED("strexh r0, r1, [r2]") > > > > - TEST_UNSUPPORTED("strexd r0, r1, [r2]") > > > > + TEST_UNSUPPORTED("strexd r0, r1, r2, [r2]") > > > > TEST_UNSUPPORTED("ldrexb r0, [r1]") > > > > TEST_UNSUPPORTED("ldrexh r0, [r1]") > > > > - TEST_UNSUPPORTED("ldrexd r0, [r1]") > > > > + TEST_UNSUPPORTED("ldrexd r0, r1, [r1]") > > > > > > > > TEST_GROUP("Data-processing (shifted register) and (modified immediate)") > > > > > > > > #define _DATA_PROCESSING32_DNM(op,s,val) \ > > > > - TEST_RR(op s".w r0, r",1, VAL1,", r",2, val, "") \ > > > > + TEST_RR(op s" r0, r",1, VAL1,", r",2, val, "") \ > > > > > > What is wrong with these .w suffixes? Shouldn't the assembler accept > > > these even on instructions that only exist in a wide encoding? > > > > I don't know if that is a bug in the integrated assembler or > > intentional behavior, but it may be easier to just change the > > kernel than the compiler in this case, as it also makes it work > > for older versions. > > > > FWIW, I needed a related change in a couple of other files: > > > > For fully specified test cases, I suppose removing the .w is fine. But > for the macros below, it really isn't: it depends on the actual > register assignment whether narrow encodings exist or not, and in that > case, we definitely want the wide one. The fact that instantiating the > macro in a different way can only produce wide encodings in the first > place should really not trigger an error. > > Things like this can break the Thumb2 build very subtly, so if the > integrated assembler is not up to that, we should simply disable it > for Thumb2 builds. > As mentioned in issue #1271, my observation here is not entirely accurate. In the general case, macros that take register names as inputs can produce narrow or wide opcodes depending on which exact registers are being used (narrow opcodes mostly only support registers r0-r7) However, in this particular case, all the ldr/str instructions are either the pre-indexed or the post-indexed variants, for which only a wide encoding exists, and so omitting the .w suffix is safe here. However, if we apply the change below, can we please document this in a comment, i.e., that encoding T4 is used for LDR/STR, and so the result is guaranteed to be wide in spite of the missing suffix? > > diff --git a/arch/arm/lib/copy_from_user.S b/arch/arm/lib/copy_from_user.S > > index 6acdfde56849..3ced01d9afe4 100644 > > --- a/arch/arm/lib/copy_from_user.S > > +++ b/arch/arm/lib/copy_from_user.S > > @@ -60,7 +60,7 @@ > > #define LDR1W_SHIFT 0 > > > > .macro ldr1w ptr reg abort > > - USERL(\abort, W(ldr) \reg, [\ptr], #4) > > + USERL(\abort, ldr \reg, [\ptr], #4) > > .endm > > > > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort > > @@ -80,7 +80,7 @@ > > #define STR1W_SHIFT 0 > > > > .macro str1w ptr reg abort > > - W(str) \reg, [\ptr], #4 > > + str \reg, [\ptr], #4 > > .endm > > > > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort > > diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S > > index 485fa3cffdbe..a6a96f814720 100644 > > --- a/arch/arm/lib/copy_to_user.S > > +++ b/arch/arm/lib/copy_to_user.S > > @@ -34,7 +34,7 @@ > > #define LDR1W_SHIFT 0 > > > > .macro ldr1w ptr reg abort > > - W(ldr) \reg, [\ptr], #4 > > + ldr \reg, [\ptr], #4 > > .endm > > > > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort > > @@ -77,7 +77,7 @@ > > #define STR1W_SHIFT 0 > > > > .macro str1w ptr reg abort > > - USERL(\abort, W(str) \reg, [\ptr], #4) > > + USERL(\abort, str \reg, [\ptr], #4) > > .endm > > > > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort > > diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S > > index e4caf48c089f..7b980a1a4227 100644 > > --- a/arch/arm/lib/memcpy.S > > +++ b/arch/arm/lib/memcpy.S > > @@ -15,7 +15,7 @@ > > #define STR1W_SHIFT 0 > > > > .macro ldr1w ptr reg abort > > - W(ldr) \reg, [\ptr], #4 > > + ldr \reg, [\ptr], #4 > > .endm > > > > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort > > @@ -31,7 +31,7 @@ > > .endm > > > > .macro str1w ptr reg abort > > - W(str) \reg, [\ptr], #4 > > + str \reg, [\ptr], #4 > > .endm > > > > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort > > diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S > > index 6fecc12a1f51..35c5c06b7588 100644 > > --- a/arch/arm/lib/memmove.S > > +++ b/arch/arm/lib/memmove.S > > @@ -84,24 +84,24 @@ WEAK(memmove) > > addne pc, pc, ip @ C is always clear here > > b 7f > > 6: W(nop) > > - W(ldr) r3, [r1, #-4]! > > - W(ldr) r4, [r1, #-4]! > > - W(ldr) r5, [r1, #-4]! > > - W(ldr) r6, [r1, #-4]! > > - W(ldr) r7, [r1, #-4]! > > - W(ldr) r8, [r1, #-4]! > > - W(ldr) lr, [r1, #-4]! > > + ldr r3, [r1, #-4]! > > + ldr r4, [r1, #-4]! > > + ldr r5, [r1, #-4]! > > + ldr r6, [r1, #-4]! > > + ldr r7, [r1, #-4]! > > + ldr r8, [r1, #-4]! > > + ldr lr, [r1, #-4]! > > > > add pc, pc, ip > > nop > > W(nop) > > - W(str) r3, [r0, #-4]! > > - W(str) r4, [r0, #-4]! > > - W(str) r5, [r0, #-4]! > > - W(str) r6, [r0, #-4]! > > - W(str) r7, [r0, #-4]! > > - W(str) r8, [r0, #-4]! > > - W(str) lr, [r0, #-4]! > > + str r3, [r0, #-4]! > > + str r4, [r0, #-4]! > > + str r5, [r0, #-4]! > > + str r6, [r0, #-4]! > > + str r7, [r0, #-4]! > > + str r8, [r0, #-4]! > > + str lr, [r0, #-4]! > > > > CALGN( bcs 2b ) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 20FC2C433E0 for ; Sat, 13 Feb 2021 11:02:36 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CE00764DD9 for ; Sat, 13 Feb 2021 11:02:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CE00764DD9 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=AyWvSWaOIiXXJBfpljWUbfoW1bYlaxjvDH0u6lH7aFI=; b=A2TkPKRJi8FZrenHZgA3Z92T+ 6x/2a267bBUrP+TP69sr3PIHgESfsOgw39HFy8QUsZAewxaVuKe6U4X5BZOFrPil0t1YhRCqz44pw biI2mETktygWLxWhrWxZbVYBMRl1y7ZwSOGffAKcnQ6pCD5L/gdZPa40MP8767gV7/CjB7Y7mJZDw AoUm7PJK/a6qcRTVh0PrEIjnn3n0mNvyRdeXKOCK37xanD1Qhao65Tjq66QaWi4mSmXzRaAxNlpxw puTgFf49+60kLWNxxS+lRNAH5sSTBVlvqa8+rmFzB+LA3kMNszOaJb1EO3r4q86BVX2CPkYidttSH 51y7x2k8g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAsg4-0005l8-5c; Sat, 13 Feb 2021 11:01:28 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1lAsg1-0005kc-C2 for linux-arm-kernel@lists.infradead.org; Sat, 13 Feb 2021 11:01:26 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id EA87764DD6 for ; Sat, 13 Feb 2021 11:01:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1613214083; bh=G71u7RTd4A+rBB1I9GNDIIEuu107tc6tTr/aifGEocg=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=GxERvQ0VZIYnBHwi/rOGp9DB578dL+KH+k7p8P662CGeWvdboRzfuzLuCr5sfmEgv kWmT5MswkYSl2Ws4Xctgd6mpy4+2ilQmFBOa/qXQc0Rl2CSLsZ/Fccvyp5/Uu1+rj/ 3rFHXqglXncFU7yoMyYc2JGJvuiWjwIT19EuRqCkFUyxmlvLTdgIBUZg7VWIMLPefh VitmMS4egfS7kwjcsF4QMuMoxuMv9NeLnnwQMQlIqBDQyhnczuu/z/oKzFj+kT1n7/ KqzCF1E4Wir/qJY2512e6WhkcrgPJLew/1xm+YnimDrPJbfAMwH9RDIkbzOZqhq52l yzv3X8rb4uo1g== Received: by mail-ot1-f54.google.com with SMTP id c16so1729148otp.0 for ; Sat, 13 Feb 2021 03:01:22 -0800 (PST) X-Gm-Message-State: AOAM532b/54mqgnAInhr3Ga/E7PkMz3ShgZAap7nkjpEqAC5bp6dCKGd 3PlWCZGOKBgnaf7dkEVoZyySanyaCCidf9ybHC8= X-Google-Smtp-Source: ABdhPJwbPg/JYsOrKxV0akZHoER+jZQufik0pH+YRE9RS6ub2wS5g0Dx/2q5znjGky9VctmOud4xL7YUR21sYDAMGVU= X-Received: by 2002:a05:6830:13ce:: with SMTP id e14mr4959394otq.108.1613214082190; Sat, 13 Feb 2021 03:01:22 -0800 (PST) MIME-Version: 1.0 References: <20210128193422.241155-1-ndesaulniers@google.com> In-Reply-To: From: Ard Biesheuvel Date: Sat, 13 Feb 2021 12:01:10 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] ARM: kprobes: rewrite test-[arm|thumb].c in UAL To: Arnd Bergmann X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210213_060125_546973_E0A8CA68 X-CRM114-Status: GOOD ( 28.66 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Arnd Bergmann , Nick Desaulniers , Russell King , Linux Kernel Mailing List , clang-built-linux , Nathan Chancellor , Linux ARM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, 29 Jan 2021 at 00:30, Ard Biesheuvel wrote: > > On Thu, 28 Jan 2021 at 23:28, Arnd Bergmann wrote: > > > > On Thu, Jan 28, 2021 at 10:03 PM Ard Biesheuvel wrote: > > > On Thu, 28 Jan 2021 at 20:34, Nick Desaulniers wrote: > > > > @@ -468,15 +468,15 @@ void kprobe_thumb32_test_cases(void) > > > > > > > > TEST_UNSUPPORTED("strexb r0, r1, [r2]") > > > > TEST_UNSUPPORTED("strexh r0, r1, [r2]") > > > > - TEST_UNSUPPORTED("strexd r0, r1, [r2]") > > > > + TEST_UNSUPPORTED("strexd r0, r1, r2, [r2]") > > > > TEST_UNSUPPORTED("ldrexb r0, [r1]") > > > > TEST_UNSUPPORTED("ldrexh r0, [r1]") > > > > - TEST_UNSUPPORTED("ldrexd r0, [r1]") > > > > + TEST_UNSUPPORTED("ldrexd r0, r1, [r1]") > > > > > > > > TEST_GROUP("Data-processing (shifted register) and (modified immediate)") > > > > > > > > #define _DATA_PROCESSING32_DNM(op,s,val) \ > > > > - TEST_RR(op s".w r0, r",1, VAL1,", r",2, val, "") \ > > > > + TEST_RR(op s" r0, r",1, VAL1,", r",2, val, "") \ > > > > > > What is wrong with these .w suffixes? Shouldn't the assembler accept > > > these even on instructions that only exist in a wide encoding? > > > > I don't know if that is a bug in the integrated assembler or > > intentional behavior, but it may be easier to just change the > > kernel than the compiler in this case, as it also makes it work > > for older versions. > > > > FWIW, I needed a related change in a couple of other files: > > > > For fully specified test cases, I suppose removing the .w is fine. But > for the macros below, it really isn't: it depends on the actual > register assignment whether narrow encodings exist or not, and in that > case, we definitely want the wide one. The fact that instantiating the > macro in a different way can only produce wide encodings in the first > place should really not trigger an error. > > Things like this can break the Thumb2 build very subtly, so if the > integrated assembler is not up to that, we should simply disable it > for Thumb2 builds. > As mentioned in issue #1271, my observation here is not entirely accurate. In the general case, macros that take register names as inputs can produce narrow or wide opcodes depending on which exact registers are being used (narrow opcodes mostly only support registers r0-r7) However, in this particular case, all the ldr/str instructions are either the pre-indexed or the post-indexed variants, for which only a wide encoding exists, and so omitting the .w suffix is safe here. However, if we apply the change below, can we please document this in a comment, i.e., that encoding T4 is used for LDR/STR, and so the result is guaranteed to be wide in spite of the missing suffix? > > diff --git a/arch/arm/lib/copy_from_user.S b/arch/arm/lib/copy_from_user.S > > index 6acdfde56849..3ced01d9afe4 100644 > > --- a/arch/arm/lib/copy_from_user.S > > +++ b/arch/arm/lib/copy_from_user.S > > @@ -60,7 +60,7 @@ > > #define LDR1W_SHIFT 0 > > > > .macro ldr1w ptr reg abort > > - USERL(\abort, W(ldr) \reg, [\ptr], #4) > > + USERL(\abort, ldr \reg, [\ptr], #4) > > .endm > > > > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort > > @@ -80,7 +80,7 @@ > > #define STR1W_SHIFT 0 > > > > .macro str1w ptr reg abort > > - W(str) \reg, [\ptr], #4 > > + str \reg, [\ptr], #4 > > .endm > > > > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort > > diff --git a/arch/arm/lib/copy_to_user.S b/arch/arm/lib/copy_to_user.S > > index 485fa3cffdbe..a6a96f814720 100644 > > --- a/arch/arm/lib/copy_to_user.S > > +++ b/arch/arm/lib/copy_to_user.S > > @@ -34,7 +34,7 @@ > > #define LDR1W_SHIFT 0 > > > > .macro ldr1w ptr reg abort > > - W(ldr) \reg, [\ptr], #4 > > + ldr \reg, [\ptr], #4 > > .endm > > > > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort > > @@ -77,7 +77,7 @@ > > #define STR1W_SHIFT 0 > > > > .macro str1w ptr reg abort > > - USERL(\abort, W(str) \reg, [\ptr], #4) > > + USERL(\abort, str \reg, [\ptr], #4) > > .endm > > > > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort > > diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S > > index e4caf48c089f..7b980a1a4227 100644 > > --- a/arch/arm/lib/memcpy.S > > +++ b/arch/arm/lib/memcpy.S > > @@ -15,7 +15,7 @@ > > #define STR1W_SHIFT 0 > > > > .macro ldr1w ptr reg abort > > - W(ldr) \reg, [\ptr], #4 > > + ldr \reg, [\ptr], #4 > > .endm > > > > .macro ldr4w ptr reg1 reg2 reg3 reg4 abort > > @@ -31,7 +31,7 @@ > > .endm > > > > .macro str1w ptr reg abort > > - W(str) \reg, [\ptr], #4 > > + str \reg, [\ptr], #4 > > .endm > > > > .macro str8w ptr reg1 reg2 reg3 reg4 reg5 reg6 reg7 reg8 abort > > diff --git a/arch/arm/lib/memmove.S b/arch/arm/lib/memmove.S > > index 6fecc12a1f51..35c5c06b7588 100644 > > --- a/arch/arm/lib/memmove.S > > +++ b/arch/arm/lib/memmove.S > > @@ -84,24 +84,24 @@ WEAK(memmove) > > addne pc, pc, ip @ C is always clear here > > b 7f > > 6: W(nop) > > - W(ldr) r3, [r1, #-4]! > > - W(ldr) r4, [r1, #-4]! > > - W(ldr) r5, [r1, #-4]! > > - W(ldr) r6, [r1, #-4]! > > - W(ldr) r7, [r1, #-4]! > > - W(ldr) r8, [r1, #-4]! > > - W(ldr) lr, [r1, #-4]! > > + ldr r3, [r1, #-4]! > > + ldr r4, [r1, #-4]! > > + ldr r5, [r1, #-4]! > > + ldr r6, [r1, #-4]! > > + ldr r7, [r1, #-4]! > > + ldr r8, [r1, #-4]! > > + ldr lr, [r1, #-4]! > > > > add pc, pc, ip > > nop > > W(nop) > > - W(str) r3, [r0, #-4]! > > - W(str) r4, [r0, #-4]! > > - W(str) r5, [r0, #-4]! > > - W(str) r6, [r0, #-4]! > > - W(str) r7, [r0, #-4]! > > - W(str) r8, [r0, #-4]! > > - W(str) lr, [r0, #-4]! > > + str r3, [r0, #-4]! > > + str r4, [r0, #-4]! > > + str r5, [r0, #-4]! > > + str r6, [r0, #-4]! > > + str r7, [r0, #-4]! > > + str r8, [r0, #-4]! > > + str lr, [r0, #-4]! > > > > CALGN( bcs 2b ) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel