regression with binutils 2.28 for ppc
Alan Modra
amodra@gmail.com
Wed Feb 23 08:51:41 GMT 2022
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
More information about the Binutils
mailing list