From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x434.google.com (mail-pf1-x434.google.com [IPv6:2607:f8b0:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id 733A83858D20 for ; Fri, 18 Feb 2022 01:34:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 733A83858D20 Received: by mail-pf1-x434.google.com with SMTP id l19so1137419pfu.2 for ; Thu, 17 Feb 2022 17:34:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=Yy8wbGKcvbD0spjOC4lTKL126Pwz6/r3NcJarSX5g8I=; b=4ROHwMsRWVJcvsvSkz/4NqAmrX3weenoJkmmkOioorg2/XkJL8bobue/GCJgzbsPrF ikJUX038Yl2LC/OD41m7c5MX7ivdmrWKio7Qt6fsUfVIN2QwuCXWdCM8fqvyJSvhltuF h+S4g7PghEpS2708BUxICJvAN9sc2ENRl8N8ljyY+JA87FeQ0cfC7Hgh67BXUWOGvd6G afwe9wENNqtGTwsYQho4MqBwmYtALEbeOcOqHkc8Bpp7k7Hc/hm1N/kH6iSh8w183dqC cS0JsnJASN1tMEQ+6xX/iRXeqiI99HIkfYcWyVWhapHgZazykGydrlCv54JfdTI1P5pf ZMdQ== X-Gm-Message-State: AOAM533kQGOHJsMzAbFIO6cYdhjFrj0PsIBxFgt1SMUtCg6qyI+z0tbN pYPTp49pfFekrgpD9/ZJi2l1kRRWuSY= X-Google-Smtp-Source: ABdhPJx3Pc2yTHE0NytsTWiakwBVwz1vvi+Shqbsb5WwL3GhquY38bibvpBF0TNaNTFKzscDgmzNZQ== X-Received: by 2002:a05:6a00:ad4:b0:4df:ffdd:5099 with SMTP id c20-20020a056a000ad400b004dfffdd5099mr5449910pfl.61.1645148064533; Thu, 17 Feb 2022 17:34:24 -0800 (PST) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id v10sm819697pfu.38.2022.02.17.17.34.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 17:34:23 -0800 (PST) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 8B3711140086; Fri, 18 Feb 2022 12:04:20 +1030 (ACDT) Date: Fri, 18 Feb 2022 12:04:20 +1030 From: Alan Modra To: Peter Bergner Cc: Waldemar Brodkorb , binutils@sourceware.org Subject: Re: regression with binutils 2.28 for ppc Message-ID: References: <8b8a3144-5c59-786f-a2ba-6f8813d60845@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <8b8a3144-5c59-786f-a2ba-6f8813d60845@linux.ibm.com> X-Spam-Status: No, score=-3031.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2022 01:34:27 -0000 On Thu, Feb 17, 2022 at 02:03:24PM -0600, Peter Bergner wrote: > On 2/17/22 3:28 AM, Waldemar Brodkorb wrote: > > -mcpu=3Dpowerpc -mbig-endian -m32 -msoft-float -mcpu=3Dpowerpc64 -mno-a= ltivec -mno-vsx >=20 > So a 32-bit compile, which is why the assembler complains about ptesync. Not from what you posted there. The last -mcpu=3Dpowerpc64 ought to enable ppc64. If you remove that, then yes, you'll get a complaint about ptesync. > You could try adding -Wa,-mppc64 or -Wa,-many to your options as a work a= round. > Newish GCCs removed passing -many to the assembler and the commit you > mentioned changed handling of sticky cpu options which is exposing the > issue. =20 -Wa cpu hacks won't work any more. gcc emits a .machine directive early in the assembly output that will override them. I think that early .machine is just plain wrong. .machine ought to only be emitted by gcc to handle something like a pragma or attribute changing code generation. That's the only compromise I can see to satisfy the disparate users of the toolchain. On the one hand you have developers who'd like an error when they accidentally use the wrong assembly (and gcc developers who'd rather not find out gcc is emitting invalid instructions by user reports of crashes!), and on the other hand you have kernel delelopers who need to write code supporting a whole range of cpus who just want the assembler to accept anything. > The use of those ptesyncs in the kernel really needs to be audited though! > If they are legitimate, then the inline assembler needs to wrap their > use with ".machine push ; .machine ppc64 ; ptesync ; .machine pop". Right. Or we should allow the user command line to control the assembler, even with -Wa,-many if they so desire. But that's killed by that stupid .machine from gcc. I didn't even get as far as Waldemar. With recent gcc, binutils and linux git source my ARCH=3Dpowerpc CROSS_COMPILE=3Dpowerpc-linux- pmac32_defconfig kernel compile bombs here: powerpc-linux-gcc -Wp,-MMD,arch/powerpc/kernel/ptrace/.ptrace.o.d -nostdinc= -I./arch/powerpc/include -I./arch/powerpc/include/generated -I./include -= I./arch/powerpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./in= clude/uapi -I./include/generated/uapi -include ./include/linux/compiler-ver= sion.h -include ./include/linux/kconfig.h -include ./include/linux/compiler= _types.h -D__KERNEL__ -I ./arch/powerpc -fmacro-prefix-map=3D./=3D -Wall -W= undef -Werror=3Dstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-= common -fshort-wchar -fno-PIE -Werror=3Dimplicit-function-declaration -Werr= or=3Dimplicit-int -Werror=3Dreturn-type -Wno-format-security -std=3Dgnu89 -= mcpu=3Dpowerpc -mcpu=3Dpowerpc -mbig-endian -m32 -msoft-float -pipe -ffixed= -r2 -mmultiple -mno-readonly-in-sdata -mcpu=3Dpowerpc64 -mno-altivec -mno-v= sx -fno-asynchronous-unwind-tables -mno-string -Wa,-maltivec -mbig-endian -= mstack-protector-guard=3Dtls -mstack-protector-guard-reg=3Dr2 -fno-delete-n= ull-pointer-checks -Wno-frame-address -Wno-format-truncation -Wno-format-ov= erflow -Wno-address-of-packed-member -O2 -fno-allow-store-data-races -Wfram= e-larger-than=3D1024 -fstack-protector-strong -Wimplicit-fallthrough=3D5 -W= no-main -Wno-unused-but-set-variable -Wno-unused-const-variable -fomit-fram= e-pointer -ftrivial-auto-var-init=3Dzero -fno-stack-clash-protection -Wdecl= aration-after-statement -Wvla -Wno-pointer-sign -Wcast-function-type -Wno-s= tringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-= overflow -Wno-restrict -Wno-maybe-uninitialized -Wno-alloc-size-larger-than= -fno-strict-overflow -fno-stack-check -fconserve-stack -Werror=3Ddate-time= -Werror=3Dincompatible-pointer-types -Werror=3Ddesignated-init -Wno-packed= -not-aligned -mstack-protector-guard-offset=3D576 -Werror -DKBUILD_MODFI= LE=3D'"arch/powerpc/kernel/ptrace/ptrace"' -DKBUILD_BASENAME=3D'"ptrace"' -= DKBUILD_MODNAME=3D'"ptrace"' -D__KBUILD_MODNAME=3Dkmod_ptrace -c -o arch/po= werpc/kernel/ptrace/ptrace.o arch/powerpc/kernel/ptrace/ptrace.c=20 {standard input}: Assembler messages: {standard input}:997: Error: unrecognized opcode: `mfsrin' {standard input}:1003: Error: unrecognized opcode: `mtsrin' {standard input}:1028: Error: unrecognized opcode: `mfsrin' {standard input}:1034: Error: unrecognized opcode: `mtsrin' {standard input}:1061: Error: unrecognized opcode: `mfsrin' {standard input}:1067: Error: unrecognized opcode: `mtsrin' make[3]: *** [scripts/Makefile.build:288: arch/powerpc/kernel/ptrace/ptrace= =2Eo] Error 1 So, last -mcpu is powerpc64. gas quite correctly flags an error on instructions phased out for ppc64. --=20 Alan Modra Australia Development Lab, IBM