Re: Define __start/__stop symbols when there is only a dynamic def

[Michael Matz <matz at suse dot de>]

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.