Re: regression with binutils 2.28 for ppc

[Alan Modra <amodra@gmail.com>]

On Sun, Feb 20, 2022 at 10:28:06PM +1030, Alan Modra wrote:
> 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.

That didn't work, because gcc pr59828 isn't fixed and what is on the
gas command line for the kernel compile is incorrect.  The .machine is
*not* a subset of the command line options.  I'm not going to try more
complicated hacks in gas trying to deduce what gcc really should have
passed on 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).

All things considered, I think all I can do in gas is to partially
revert commit b25f942e18d6 which made .machine more strict.  At least
that way -many (passed by release gcc) or other user sticky -Wa
options like -maltivec will not be lost.  Bad luck if a user wants
-mcpu=power9 -Wa,-power10 for example.

	* config/tc-ppc.c (ppc_machine): Treat an early .machine specially,
	keeping sticky options to work around gcc bugs.

diff --git a/gas/config/tc-ppc.c b/gas/config/tc-ppc.c
index 054f9c72161..89bc7d3f9b9 100644
--- a/gas/config/tc-ppc.c
+++ b/gas/config/tc-ppc.c
@@ -5965,7 +5965,30 @@ ppc_machine (int ignore ATTRIBUTE_UNUSED)
 	     options do not count as a new machine, instead they add
 	     to currently selected opcodes.  */
 	  ppc_cpu_t machine_sticky = 0;
-	  new_cpu = ppc_parse_cpu (ppc_cpu, &machine_sticky, cpu_string);
+	  /* Unfortunately, some versions of gcc emit a .machine
+	     directive very near the start of the compiler's assembly
+	     output file.  This is bad because it overrides user -Wa
+	     cpu selection.  Worse, there are versions of gcc that
+	     emit the *wrong* cpu, not even respecting the -mcpu given
+	     to gcc.  See gcc pr101393.  And to compound the problem,
+	     as of 20220222 gcc doesn't pass the correct cpu option to
+	     gas on the command line.  See gcc pr59828.  Hack around
+	     this by keeping sticky options for an early .machine.  */
+	  asection *sec;
+	  for (sec = stdoutput->sections; sec != NULL; sec = sec->next)
+	    {
+	      segment_info_type *info = seg_info (sec);
+	      /* Are the frags for this section perturbed from their
+		 initial state?  Even .align will count here.  */
+	      if (info != NULL
+		  && (info->frchainP->frch_root != info->frchainP->frch_last
+		      || info->frchainP->frch_root->fr_type != rs_fill
+		      || info->frchainP->frch_root->fr_fix != 0))
+		break;
+	    }
+	  new_cpu = ppc_parse_cpu (ppc_cpu,
+				   sec == NULL ? &sticky : &machine_sticky,
+				   cpu_string);
 	  if (new_cpu != 0)
 	    ppc_cpu = new_cpu;
 	  else

-- 
Alan Modra
Australia Development Lab, IBM