V2 [PATCH] LTO: Ignore undefined symbols without relocation

Alan Modra amodra@gmail.com
Mon Aug 3 07:26:43 GMT 2020


On Fri, Jul 31, 2020 at 08:47:44AM -0700, H.J. Lu wrote:
> On Fri, Jul 31, 2020 at 4:43 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > I compared the results of my fix vs yours:
> >
> >   text    data     bss     dec     hex filename
> >   46357    1408     712   48477    bd5d yours
> >   45731    1408     712   47851    baeb mine
> >
> >  One difference is that my fix doesn't have
> >
> > +                 U abort@@GLIBC_2.2.5
> > +                 U access@@GLIBC_2.2.5
> > +                 U __assert_fail@@GLIBC_2.2.5
> > +                 U bfd_arch_list
> > +                 U bfd_close_all_done
> > +                 U bfd_iterate_over_targets
> > +                 U bfd_printable_arch_mach
> > +                 U bfd_scan_vma
> > +                 U getenv@@GLIBC_2.2.5
> > +                 U memset@@GLIBC_2.2.5
> > +                 U mkdtemp@@GLIBC_2.2.5
> > +                 U mkstemps@@GLIBC_2.11
> > +                 U __realpath_chk@@GLIBC_2.4
> > +                 U strcpy@@GLIBC_2.2.5
> > +                 U strdup@@GLIBC_2.2.5
> > +                 U strncmp@@GLIBC_2.2.5
> >
> > in dynamic symbol table.   There are no dynamic relocations against
> > these symbols.  These are caused by GCC bug:
> >
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96385

Right, as expected.

> > My patch removes these symbol from dynamic symbol table:
> >
> > https://sourceware.org/bugzilla/show_bug.cgi?id=26324
> >
> 
> Here is the updated patch with a testcase.  OK for master?

In general I'm not against fixing gcc problems via linker patches, but
in this case it seems that we don't have an incorrect code bug any
more.  So why are we worried about unnecessary dynamic symbols to the
extent that linker patches are needed rather than fixing the problem
in gcc?

-- 
Alan Modra
Australia Development Lab, IBM


More information about the Binutils mailing list