[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