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=-10.5 required=3.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED,DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS, HTML_MESSAGE,INCLUDES_PATCH,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 621B0C63777 for ; Fri, 27 Nov 2020 03:14:33 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (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 4A9172222A for ; Fri, 27 Nov 2020 03:14:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=google.com header.i=@google.com header.b="tgCdr1PR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4A9172222A Authentication-Results: mail.kernel.org; dmarc=fail (p=reject dis=none) header.from=google.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from bilbo.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 4Cj0920b6rzDrWN for ; Fri, 27 Nov 2020 14:14:30 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=google.com (client-ip=2a00:1450:4864:20::644; helo=mail-ej1-x644.google.com; envelope-from=morbo@google.com; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=google.com header.i=@google.com header.a=rsa-sha256 header.s=20161025 header.b=tgCdr1PR; dkim-atps=neutral Received: from mail-ej1-x644.google.com (mail-ej1-x644.google.com [IPv6:2a00:1450:4864:20::644]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4ChxQq6N1WzDrRd for ; Fri, 27 Nov 2020 12:11:14 +1100 (AEDT) Received: by mail-ej1-x644.google.com with SMTP id bo9so5251195ejb.13 for ; Thu, 26 Nov 2020 17:11:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0x4nnMkHcynIez1nPznTtPoKd0WmmPj/YGGV6xq0FUE=; b=tgCdr1PRZnQAPP3RhQdUpBOOHDOJzOuR4vk/r34HGPr/R0ayg1kjfsD81VCdEBK3Wn rhrTYCGhNmoxfoQ60/4maRUQ9Xah9REElwhfvsFLvohbJOUV3CqTQrzAcgWUBfXMHMhN fpECI5dWaBaNb8DOungnsz3JeWL5WwUWo9ga9EUMFColH5G1zgx3yDqK3+myK41DqFXq zGfa2MkJLBJNXf65u1UREI7IuoIAE4r6ZmWpZOvl6KrgA7HKJL6C4O1TsJq88SlTMOnT 8NmilErB1/UEZoqiFjucErdR5jImebtAXod1AH4193L4L3SS7ewryyvzpXywME3EdGMB GUKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0x4nnMkHcynIez1nPznTtPoKd0WmmPj/YGGV6xq0FUE=; b=q1sME+leKDEONYQGmKH+Q2KdvhcASz9QsM2Q/8KkoDdzvZb9bEM0SmnG3zYgek8r80 egTSQF5kG+zs4ZgObTfQvV+kGwhKJRZlUcy/X8DqOZCyfDJqIroMDWj1ZlEj9DgQ5ewY 4qYmoDG06PgFjI7MCJEywcZEtZgqdoYH1hqNDfZvPcLHmjpzjTkCL48fdrQjn5p1IgH7 YCSvYmfoDa+i0lq+gngxMEduLDijb1NlzBAmir4umHBXtQeBkAna7PDquDcAkczedjxJ HYhvS6nokMonGYzmE9ORk7zv2+tW6XPixfvO/528Koz0+vvlPMrVysllHfUdhQwckm8E JaNA== X-Gm-Message-State: AOAM5316y7O0BAALrRW5zc+yGX3tFMDEi4B/8L8KQMtdS8bNkFNYGSuF Zaa56byq9xCywD63ledlgg1UvlmO6rE0AacOnxDx X-Google-Smtp-Source: ABdhPJx7DPhieTAUdX6zqWDIbfUxbJF1apdounJSq6WQT/TnnHw9MaKco2Njpec35HFlgipTbuKnjzHdGAGfGRK2b28= X-Received: by 2002:a17:906:4704:: with SMTP id y4mr5067521ejq.449.1606439469517; Thu, 26 Nov 2020 17:11:09 -0800 (PST) MIME-Version: 1.0 References: <20201118223513.2704722-1-morbo@google.com> <20201120224034.191382-1-morbo@google.com> <20201120224034.191382-4-morbo@google.com> <87d0041vaf.fsf@mpe.ellerman.id.au> <20201123063432.GG2672@gate.crashing.org> <20201123195622.GI2672@gate.crashing.org> <20201123200846.GJ2672@gate.crashing.org> <87zh37zaf4.fsf@mpe.ellerman.id.au> <87ft4vy5jp.fsf@mpe.ellerman.id.au> In-Reply-To: <87ft4vy5jp.fsf@mpe.ellerman.id.au> From: Bill Wendling Date: Thu, 26 Nov 2020 17:10:57 -0800 Message-ID: Subject: Re: [PATCH v3 3/3] powerpc/64s: feature: Work around inline asm issues To: Michael Ellerman Content-Type: multipart/alternative; boundary="000000000000ef922505b50c55c3" X-Mailman-Approved-At: Fri, 27 Nov 2020 14:12:45 +1100 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Nick Desaulniers , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" --000000000000ef922505b50c55c3 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 26, 2020, 5:03 PM Michael Ellerman wrote: > Bill Wendling writes: > > On Mon, Nov 23, 2020 at 7:44 PM Michael Ellerman > wrote: > >> Bill Wendling writes: > >> > On Mon, Nov 23, 2020 at 12:10 PM Segher Boessenkool > >> > wrote: > >> >> On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling wrote: > >> >> > On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool > >> >> > wrote: > >> >> > > > On Sun, Nov 22, 2020 at 10:36 PM Segher Boessenkool > >> >> > > > wrote: > >> >> > > > > "true" (as a result of a comparison) in as is -1, not 1. > >> >> > > > >> >> > > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill Wendling wrote: > >> >> > > > What Segher said. :-) Also, if you reverse the comparison, > you'll get > >> >> > > > a build error. > >> >> > > > >> >> > > But that means your patch is the wrong way around? > >> >> > > > >> >> > > - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \ > >> >> > > - .error "Feature section else case larger than body"; \ > >> >> > > - .endif; \ > >> >> > > + .org . - ((label##4b-label##3b) > > (label##2b-label##1b)); \ > >> >> > > > >> >> > > It should be a + in that last line, not a -. > >> >> > > >> >> > I said so in a follow up email. > >> >> > >> >> Yeah, and that arrived a second after I pressed "send" :-) > >> >> > >> > Michael, I apologize for the churn with these patches. I believe the > >> > policy is to resend the match as "v4", correct? > >> > > >> > I ran tests with the change above. It compiled with no error. If I > >> > switch the labels around to ".org . + ((label##2b-label##1b) > > >> > (label##4b-label##3b))", then it fails as expected. > >> > >> I wanted to retain the nicer error reporting for gcc builds, so I did it > >> like this: > >> > >> diff --git a/arch/powerpc/include/asm/feature-fixups.h > b/arch/powerpc/include/asm/feature-fixups.h > >> index b0af97add751..c4ad33074df5 100644 > >> --- a/arch/powerpc/include/asm/feature-fixups.h > >> +++ b/arch/powerpc/include/asm/feature-fixups.h > >> @@ -36,6 +36,24 @@ label##2: > \ > >> .align 2; \ > >> label##3: > >> > >> + > >> +#ifndef CONFIG_CC_IS_CLANG > >> +#define CHECK_ALT_SIZE(else_size, body_size) \ > >> + .ifgt (else_size) - (body_size); \ > >> + .error "Feature section else case larger than body"; \ > >> + .endif; > >> +#else > >> +/* > >> + * If we use the ifgt syntax above, clang's assembler complains about > the > >> + * expression being non-absolute when the code appears in an inline > assembly > >> + * statement. > >> + * As a workaround use an .org directive that has no effect if the > else case > >> + * instructions are smaller than the body, but fails otherwise. > >> + */ > >> +#define CHECK_ALT_SIZE(else_size, body_size) \ > >> + .org . + ((else_size) > (body_size)); > >> +#endif > >> + > >> #define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect) \ > >> label##4: \ > >> .popsection; \ > >> @@ -48,9 +66,7 @@ label##5: > \ > >> FTR_ENTRY_OFFSET label##2b-label##5b; \ > >> FTR_ENTRY_OFFSET label##3b-label##5b; \ > >> FTR_ENTRY_OFFSET label##4b-label##5b; \ > >> - .ifgt (label##4b- label##3b)-(label##2b- label##1b); \ > >> - .error "Feature section else case larger than body"; \ > >> - .endif; \ > >> + CHECK_ALT_SIZE((label##4b-label##3b), (label##2b-label##1b)); \ > >> .popsection; > >> > >> > >> > >> I've pushed a branch with all your patches applied to: > >> > >> https://github.com/linuxppc/linux/commits/next-test > >> > > This works for me. Thanks! > > Great. > > >> Are you able to give that a quick test? It builds clean with clang for > >> me, but we must be using different versions of clang because my branch > >> already builds clean for me even without your patches. > >> > > You may need to set LLVM_IAS=1 to get the behavior I'm seeing. That > > turns on clang's integrated assembler, which I think is disabled by > > default. > > Yep that does it. > > But then I get: > clang: error: unsupported argument '-mpower4' to option 'Wa,' > clang: error: unsupported argument '-many' to option 'Wa,' > > So I guess I'm still missing something? > I've seen that too. I'm not entirely sure what's causing it, but I'll look into it. I've got a backlog of things to work on still. :-) It's probably a clang issue. There's another one that came up having to do with the format of some PPC instructions. I have a clang fix on review for those. > Note that with clang's integrated assembler, arch/powerpc/boot/util.S > > fails to compile. Alan Modra mentioned that he sent you a patch to > > "modernize" the file so that clang can compile it. > > Ah you're right he did, it didn't go to patchwork so I missed it. Have > grabbed it now. > Thanks! -bw > --000000000000ef922505b50c55c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Nov 26, 2020, 5:03 PM Michael Ellerman <mpe@ellerman.id.au> wrote:
Bill Wendling <morbo@google.com> = writes:
> On Mon, Nov 23, 2020 at 7:44 PM Michael Ellerman <mpe@ellerman.id.a= u> wrote:
>> Bill Wendling <morbo@google.com> writes:
>> > On Mon, Nov 23, 2020 at 12:10 PM Segher Boessenkool
>> > <segher@kernel.crashing.org> wrote:
>> >> On Mon, Nov 23, 2020 at 12:01:01PM -0800, Bill Wendling w= rote:
>> >> > On Mon, Nov 23, 2020 at 11:58 AM Segher Boessenkool<= br> >> >> > <segher@kernel.crashing.org> wrote= :
>> >> > > > On Sun, Nov 22, 2020 at 10:36 PM Segher Bo= essenkool
>> >> > > > <segher@kernel.crashing.org= > wrote:
>> >> > > > > "true" (as a result of a co= mparison) in as is -1, not 1.
>> >> > >
>> >> > > On Mon, Nov 23, 2020 at 11:43:11AM -0800, Bill = Wendling wrote:
>> >> > > > What Segher said. :-) Also, if you reverse= the comparison, you'll get
>> >> > > > a build error.
>> >> > >
>> >> > > But that means your patch is the wrong way arou= nd?
>> >> > >
>> >> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0.ifgt (label##4b- l= abel##3b)-(label##2b- label##1b);=C2=A0 =C2=A0 \
>> >> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0.error "Featur= e section else case larger than body";=C2=A0 =C2=A0 \
>> >> > > -=C2=A0 =C2=A0 =C2=A0 =C2=A0.endif;=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0\
>> >> > > +=C2=A0 =C2=A0 =C2=A0 =C2=A0.org . - ((label##4= b-label##3b) > (label##2b-label##1b)); \
>> >> > >
>> >> > > It should be a + in that last line, not a -. >> >> >
>> >> > I said so in a follow up email.
>> >>
>> >> Yeah, and that arrived a second after I pressed "sen= d" :-)
>> >>
>> > Michael, I apologize for the churn with these patches. I beli= eve the
>> > policy is to resend the match as "v4", correct?
>> >
>> > I ran tests with the change above. It compiled with no error.= If I
>> > switch the labels around to ".org . + ((label##2b-label#= #1b) >
>> > (label##4b-label##3b))", then it fails as expected.
>>
>> I wanted to retain the nicer error reporting for gcc builds, so I = did it
>> like this:
>>
>> diff --git a/arch/powerpc/include/asm/feature-fixups.h b/arch/powe= rpc/include/asm/feature-fixups.h
>> index b0af97add751..c4ad33074df5 100644
>> --- a/arch/powerpc/include/asm/feature-fixups.h
>> +++ b/arch/powerpc/include/asm/feature-fixups.h
>> @@ -36,6 +36,24 @@ label##2:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.align 2;=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>>=C2=A0 label##3:
>>
>> +
>> +#ifndef CONFIG_CC_IS_CLANG
>> +#define CHECK_ALT_SIZE(else_size, body_size)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0.ifgt (else_size) - (body_size);=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 \
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0.error "Feature section else case= larger than body";=C2=A0 =C2=A0 \
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0.endif;
>> +#else
>> +/*
>> + * If we use the ifgt syntax above, clang's assembler complai= ns about the
>> + * expression being non-absolute when the code appears in an inli= ne assembly
>> + * statement.
>> + * As a workaround use an .org directive that has no effect if th= e else case
>> + * instructions are smaller than the body, but fails otherwise. >> + */
>> +#define CHECK_ALT_SIZE(else_size, body_size)=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0.org . + ((else_size) > (body_size)= );
>> +#endif
>> +
>>=C2=A0 #define MAKE_FTR_SECTION_ENTRY(msk, val, label, sect)=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
>>=C2=A0 label##4:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.popsection;=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \
>> @@ -48,9 +66,7 @@ label##5:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0\
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FTR_ENTRY_OFFSET label##2b-label#= #5b;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FTR_ENTRY_OFFSET label##3b-label#= #5b;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<= br> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0FTR_ENTRY_OFFSET label##4b-label#= #5b;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\<= br> >> -=C2=A0 =C2=A0 =C2=A0 =C2=A0.ifgt (label##4b- label##3b)-(label##2= b- label##1b);=C2=A0 =C2=A0 \
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0.error "Feature section else case= larger than body";=C2=A0 =C2=A0 \
>> -=C2=A0 =C2=A0 =C2=A0 =C2=A0.endif;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0CHECK_ALT_SIZE((label##4b-label##3b), = (label##2b-label##1b)); \
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0.popsection;
>>
>>
>>
>> I've pushed a branch with all your patches applied to:
>>
>>=C2=A0 =C2=A0https://github.co= m/linuxppc/linux/commits/next-test
>>
> This works for me. Thanks!

Great.

>> Are you able to give that a quick test? It builds clean with clang= for
>> me, but we must be using different versions of clang because my br= anch
>> already builds clean for me even without your patches.
>>
> You may need to set LLVM_IAS=3D1 to get the behavior I'm seeing. T= hat
> turns on clang's integrated assembler, which I think is disabled b= y
> default.

Yep that does it.

But then I get:
=C2=A0 clang: error: unsupported argument '-mpower4' to option '= ;Wa,'
=C2=A0 clang: error: unsupported argument '-many' to option 'Wa= ,'

So I guess I'm still missing something?

I've seen that too. I'm = not entirely sure what's causing it, but I'll look into it. I'v= e got a backlog of things to work on still. :-) It's probably a clang i= ssue. There's another one that came up having to do with the format of = some PPC instructions. I have a clang fix on review for those.

> Note that with clang's integrated assembler, arch/powerpc/boot/uti= l.S
> fails to compile. Alan Modra mentioned that he sent you a patch to
> "modernize" the file so that clang can compile it.

Ah you're right he did, it didn't go to patchwork so I missed it. H= ave
grabbed it now.

Thanks!
-bw
= --000000000000ef922505b50c55c3--