objcopy/strip of IR files and is_strip_input

[H.J. Lu]

On Mon, Aug 11, 2025 at 5:39 PM Alan Modra <amodra@gmail.com> wrote:
>
> 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.

This is what I meant by "treat slim GCC IR and slim LLVM IR the same".
Since we don't touch slim LLVM IR, we shouldn't touch slim GCC IR.
Strip GCC IR in fat objects is OK.

> Yes, I can see your comment are 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?

There are cross references between GCC code IR and GCC debug IR.
If GCC debug IR is removed while GCC code IR is kept, we get undefined
references to debug IR from code IR.

>
> --
> Alan Modra



-- 
H.J.