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

[H.J. Lu]

On Tue, Aug 5, 2025 at 3:32 PM Alan Modra <amodra@gmail.com> wrote:
>
> 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..)

I'd like your cleanup patch.  I can submit my patch after your cleanup patch.

> 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.

I tried different options.   BFD needs a way to tell if it is called from
strip.  If we don't want a flag, we need to pass this info to BFD via
a function argument, which means introducing another interface for
checking format.

> --
> Alan Modra



-- 
H.J.