objcopy/strip of IR files and is_strip_input

[Alan Modra]

On Mon, Aug 11, 2025 at 12:58:51PM -0700, H.J. Lu wrote:
> On Mon, Aug 11, 2025 at 3:23 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > This tidies objcopy/strip handling of IR objects, in the process of
> > removing the unnecessary is_strip_input flag.
> >
> > The first thing I noticed when looking at is_strip_input code was that
> > the abfd->my_archive test in bfd_check_format_matches meant that
> > plugins were disabled when reading archive elements.  We can instead
> > disable plugins by setting bfd_no_plugin, so there doesn't seem to be
> > a need for is_strip_input in objcopy.c:copy_archive.  This isn't
> > exactly the same, because bfd_no_plugin prevents the plugin target
> > recognising archive elements in the bfd_check_format_matches loop over
> > all targets as well as just the first !target_defaulted test.  But
> > that turns out to be fine.  IR code is handled in copy_archive as for
> > other unknown format files.  In fact, the only need for the plugin
> > target when copying archives is when reading symbols for the archive
> > map.  I've made that plain by moving the plugin target override and
> > commenting on why it is really needed.
> >
> > So on to plain object files.  Here, IR code is also copied unchanged,
> > so there doesn't seem a need for the plugin target there either.  It
> > isn't quite so simple though, because the objcopy/strip code handling
> > object files wants to verify the format of the object file.  Allowing
> > objcopy/strip to copy unknown format files would be a change in
> > behaviour (and results in mmix testsuite fails, ld-mmix/b-badfil1 and
> > others).  However, always excluding the plugin target results in a
> > fail of tests added in commit c2729c37f10a.  So I've enabled a plugin
> > format check only for files that are otherwise unrecognised, and
> > commented why this is done.  I question the need to objcopy LLVM
> > bytecode files.
> 
> Will the new strip work on archives which contain regular objects
> as well as LLVM slim IR objects?

I can't see why not, and a little testing says it does work as
expected.  ie. the regular files get stripped and the LLVM slim IR
objects are left unchanged.

> > Another thing (not done in this patch): I think that both places where
> > we do something special with lto_slim_ir_object can be removed too,
> > but that causes
> > FAIL: pr33246 with --strip-debug --enable-deterministic-archives (strip tmpdir/pr33246.o)
> > due to strip-debug removing the FILE symbol but otherwise leaving the
> > object file good.  ie. the test is too restrictive IMO.  Is it true
> > that no one will ever want to manipulate slim IR files?  (Apart from
> > the currently allowed removal of all IR sections.)
> 
> Binutils recogizes and treats LLVM slim and GCC slim IR objects differently.
> I think it is better to treat them the same.  Slim IR objects should be
> always copied as unknown objects.

The actual IR yes, we can't mess with that in objcopy.  GCC slim LTO
is however an ELF object like any other.  Educate me as to why
mainline strip now should not remove a FILE symbol, and --strip-debug
not remove .gnu.debuglto_.debug* sections.  Previous binutils versions
of strip with --strip-debug did remove those sections, and a FILE
symbol.

Yes, I can see your comment added with commit c2729c37f10a
  /* NB: Must keep .gnu.debuglto_* sections unless all GCC LTO sections
     will be removed to avoid undefined references to symbols in GCC LTO
     debug sections.  */
  if (!lto_sections_removed)
    find_section_list (".gnu.debuglto_*", true, SECTION_CONTEXT_KEEP);

That doesn't make a great deal of sense to me.  Usually it is the
other way around.  ie. symbols in a non-debug section are referenced
by a debug section.  What symbols are being referenced in the
.gnu.debuglto sections and from where?

-- 
Alan Modra