regression with binutils 2.28 for ppc

[Peter Bergner]

On 2/17/22 7:34 PM, Alan Modra wrote:
> On Thu, Feb 17, 2022 at 02:03:24PM -0600, Peter Bergner wrote:
>> On 2/17/22 3:28 AM, Waldemar Brodkorb wrote:
>>> -mcpu=powerpc -mbig-endian -m32 -msoft-float -mcpu=powerpc64 -mno-altivec -mno-vsx
>>
>> So a 32-bit compile, which is why the assembler complains about ptesync.
> 
> Not from what you posted there.  The last -mcpu=powerpc64 ought to
> enable ppc64.  If you remove that, then yes, you'll get a complaint
> about ptesync.

Well it's a 32-bit compile in that the obj is Elf32:

linux$ gcc -m32 -mcpu=powerpc64 simple.c 
linux$ file a.out 
a.out: ELF 32-bit MSB executable, PowerPC or cisco 4500, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=804e1b0621e258ef9a1e4691d5f0764e4c5e852a, not stripped

That said, the -mcpu=power64 with newish gccs seems to emit a .machine ppc64.
The older gcc I was using seems to emit a ".machine ppc" which is why
I saw the same issue with ptesync when using a new binutils.


>> You could try adding -Wa,-mppc64 or -Wa,-many to your options as a work around.
>> Newish GCCs removed passing -many to the assembler and the commit you
>> mentioned changed handling of sticky cpu options which is exposing the
>> issue.  
> 
> -Wa cpu hacks won't work any more.

Ah right, thanks for correcting me!


>> 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 thought we were moving towards more reliance on .machine and not away
from it?  You think we shouldn't be?




> I didn't even get as far as Waldemar.  With recent gcc, binutils and
> linux git source my
> ARCH=powerpc CROSS_COMPILE=powerpc-linux- pmac32_defconfig
> kernel compile bombs here:
> 
[snip]
> {standard input}:997: Error: unrecognized opcode: `mfsrin'
[snip]
> So, last -mcpu is powerpc64.  gas quite correctly flags an error on
> instructions phased out for ppc64.

This is probably the difference between new gccs emiting .machine ppc64
when using -mcpu=powerpc64 and old gccs that emit .machine ppc.
One more confusing thing to have to handle! :-(


Given all the above though, I'm surprised the kernel team hasn't hit
this already and complained to us about it! :-) 


Peter