Define __start/__stop symbols when there is only a dynamic def
Michael Matz
matz@suse.de
Sat Jan 27 02:01:00 GMT 2018
Hi,
On Fri, 26 Jan 2018, H.J. Lu wrote:
> >> This patch fixes a case where a user had a C-representable named
> >> section in both the executable and shared libraries, and of course
> >> wanted the size of the local section in the executable, not the
> >> dynamic section. It does mean that __start and __stop symbols don't
> >> behave exactly like PROVIDEd symbols, but I think that's a reasonable
> >> difference particularly since this is the way they used to behave.
> >
> > Is this distinction now documented ? Ie can future users still be
> > confused by this behaviour ?
> >
> >> Nick, I'd like to apply this to the branch. I think it should be
> >> quite safe.
> >>
> >> * elflink.c (bfd_elf_define_start_stop): Override symbols when
> >> they are defined dynamically.
> >
> > Fair enough - please apply - although I do also like H.J.'s request
> > for a testcase...
> >
>
> There are testcases for:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=21964
>
> But they only check __start/__stop symbols are handled correctly.
> __size isn't checked. Let me see if I can extend them to check
> __size.
Even though Alans mail talks about size of the section, it's not about
.sizeof.FOO. The patch changes the behaviour when both, the application
and a dynamic library linked to it have a C-representable-named section,
say __verbose. Then the dynamic lib and the app should have and use their
own __start___verbose symbol (i.e. there should be two such symbols
overall). Without the patch the app won't create the symbol when the only
reference to __start___verbose comes from -u __start___verbose (i.e.
there's no ref_regular ref to it from the app).
Ciao,
Michael.
More information about the Binutils
mailing list