This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Define __start/__stop symbols when there is only a dynamic def
On Fri, Jan 26, 2018 at 6:55 AM, Michael Matz <matz@suse.de> wrote:
> 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).
>
Please open a bug report with a testcase, similar to
https://sourceware.org/bugzilla/show_bug.cgi?id=21964
which should fail without the patch.
Thanks.
--
H.J.