[PATCH v3] LTO: Restore the wrapper symbol check for standard function

H.J. Lu hjl.tools@gmail.com
Sat Aug 3 03:35:54 GMT 2024


On Sat, Aug 3, 2024, 6:31 AM Alan Modra <amodra@gmail.com> wrote:

> On Fri, Aug 02, 2024 at 07:24:24PM -0700, H.J. Lu wrote:
> > On Fri, Aug 2, 2024 at 7:01 PM Alan Modra <amodra@gmail.com> wrote:
> > > -         if (blhe && blhe->wrapper_symbol)
> > > -           wrap_status = wrapper;
> > > +         if (blhe && link_info.wrap_hash != NULL)
> > > +           {
> > > +             struct bfd_link_hash_entry *unwrap
> > > +               = unwrap_hash_lookup (&link_info, (bfd *) abfd, blhe);
> > > +             if (unwrap != h)
> > > +               wrap_status = wrapper;
> >
> > Will LTO remove __wrap_XXX when XXX isn't referenced? If not,
>
> Likely not.
>
> > this will be a regression.
>
> I can't say I'm greatly concerned about a code size regression when
> LTO and --wrap intersect, but yes, you have identified a potential
> defect in my simpler pr3195c patch.  Hmm.  If I modify your pr31956c.c
> testcase to make main just return 0, ie. not call malloc, and make
> __wrap_malloc hidden then ld 2.42 leaves __wrap_malloc defined..
>

It is because malloc is in libc.so.

I'd like to find a testcase where there is a code size regression,
> but really can't spend time today on that.
>
> --
> Alan Modra
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/binutils/attachments/20240803/a25cca74/attachment.htm>


More information about the Binutils mailing list