[PATCH] strip: Don't treat fat IR objects as plugin object

[Alan Modra]

On Tue, Aug 05, 2025 at 08:06:36AM -0700, H.J. Lu wrote:
> On Tue, Aug 5, 2025 at 7:42 AM Alan Modra <amodra@gmail.com> wrote:
> >
> > On Mon, Aug 04, 2025 at 07:59:55PM -0700, H.J. Lu wrote:
> > >       (bfd_check_format_matches_lto): Add a bool argument to indicate
> > >       called from strip.
> >
> > This seems like a poor idea to me.  I'd rather not see special cases
> > like this in bfd_check_format.  I think it would be better to keep the
> > logic in objcopy.c, even if it means closing then reopening a bfd with
> > plugins disabled via bfd_plugin_no in bfd->plugin_format.
> >
> > The following is something I worked on today, but haven't yet
> > committed.
[snip]
> This failed PR 33246 tests in my patch:

I should have made it clear that I wasn't attempting to fix PR33246
with that patch.  It was a cleanup, triggered by realising that this
comment of yours was misleading (which isn't that surprising or
reprehensible since you'd been carrying around that code since 2013):

#if BFD_SUPPORTS_PLUGINS
      /* If the plugin target is explicitly specified when a BFD file
	 is opened, don't check it twice.  */
      if (bfd_plugin_specified_p () && bfd_plugin_target_p (*target))
	continue;
#endif

That code was not there due to specifying an input target of "plugin"!
It was there to prevent a recursive call from bfd_plugin_object_p back
into bfd_check_format which could cause a segfault inside glibc when
attempting to load the plugin again while it was running.  (Which is a
glibc bug that likely should be fixed.)  After fixing that problem
using bfd_plugin_no instead, which is what bfd_plugin_object_p does
already, I noticed you could use the same flag instead of adding
lto_sections_removed.  That means bfd_check_format doesn't even need
to know about bfd_plugin_no, which better separates the logic.  (Yes,
I left it in bfd_check_format with the posted patch as I'm wary of
changing anything to do with plugins..)

If you could separate the logic with your patch for PR33246 that would
also be better.  It may not be possible, I haven't checked your
PR33246 patch in detail, but please think about a PR33246 fix that
doesn't need another bfd flag.  If you don't have the time (or
enthusiasm) to do that I won't insist on doing without another flag.

-- 
Alan Modra