Re: regression with binutils 2.28 for ppc

[Alan Modra <amodra@gmail.com>]

On Thu, Feb 17, 2022 at 10:21:30PM -0600, Peter Bergner wrote:
> On 2/17/22 7:34 PM, Alan Modra wrote:
> > On Thu, Feb 17, 2022 at 02:03:24PM -0600, Peter Bergner wrote:
> >> 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 thought it wasn't a great idea when we started using it in 2015 or
so.  You can probably find archived email of me saying that.  ;-)
Nothing has changed since then to make me think that gcc controlling
the assembler by both command-line options and a source directive at
the start of assembly is a good idea.

I'm tempted to hack gas to ignore the first .machine from gcc, if no
code has been emitted and the .machine is a subset of what is given by
the command line.

> This is probably the difference between new gccs emiting .machine ppc64
> when using -mcpu=powerpc64 and old gccs that emit .machine ppc.

Ah, gcc pr101393 (which was about 403, but same thing, .machine ppc
rather than the correct machine).

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

I guess the focus has been on 64-bit kernels.

-- 
Alan Modra
Australia Development Lab, IBM