[PATCH v2] MIPS: Don't move __gnu_lto_slim to .scommon

[Alan Modra]

On Thu, Jul 20, 2023 at 10:34:43AM +0100, Maciej W. Rozycki wrote:
> On Thu, 20 Jul 2023, Alan Modra wrote:
> 
> > I think the patch is OK, but the same should be applied to another
> > place to stop objcopy modifying __gnu_lto_slim.
> > 
> > mips-linux-gnu testcase after running make check:
> >   binutils/objcopy ld/tmpdir/pr15323a-r.o ld/tmpdir/xxx
> > then inspect ld/tmpdir/xxx with readelf.
> > 
> > I'm going to apply the following to mainline, and will also apply to
> > the 2.41 branch tomorrow if no one objects.
> 
>  You are the author of this code, so I guess you know what's going on 
> here.  I still don't understand the circumstances that cause linker.c to 
> reject this symbol if it's in an SHN_MIPS_SCOMMON rather than SHN_COMMON 
> section, and the relevant git change descriptions (going back to commit 
> b794fc1d1c3a ("Warn for ar/nm/ranlib/ld on lto objects without plugin")) 
> do not explain it, so I'd appreciate if you got me enlightened.

It isn't anything in linker.c, I believe the problem occurs in the lto
plugin which processes object files using libiberty/simple-object*.
Code in libiberty/simple-object-elf.c removes SHN_COMMON symbols,
which for most architectures removes __gnu_lto_slim, but not on mips
if the symbol is moved to SHN_MIPS_SCOMMON.  Then the symbol appears
in lto output files, resulting in linker errors like:
/tmp/ccg5JkW9.debug.temp.o: plugin needed to handle lto object

I haven't actually looked at this under gdb to see exactly what is
going on for mips, I'm relying on memory from doing so for powerpc a
while ago.

-- 
Alan Modra
Australia Development Lab, IBM