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

[Alan Modra]

On Thu, Jul 20, 2023 at 03:32:49PM +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
> 
>  It seems to me then we should be fixing libiberty instead, to also remove 
> SHN_MIPS_SCOMMON symbols, for whatever intent it's done, shouldn't we?

It would be quite reasonable to change the libiberty code to test for
EM_MIPS and SHN_MIPS_SCOMMON, or to discard __gnu_lto_slim by name.
(The only reason that simple_object_elf_copy_lto_debug_sections
removes SHN_COMMON symbols is to remove __gnu_lto_slim.)

However the symbol is a marker only, so I think it is also entirely
reasonable to stop mips ld -r or objcopy from modifying it
unexpectedly.

-- 
Alan Modra
Australia Development Lab, IBM