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

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Fri, Jan 26, 2018 at 6:01 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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.
>

I just realized it is your bug and Bugzilla crashed.  Here the email trail:

http://lists.gnu.org/archive/html/bug-binutils/2017-08/msg00195.html

Hasn't it been fixed with testcases to verify the fix?  Is testcase not
sufficient to cover your usage?  Can you take a look at

testsuite/ld-elf/pr21964-1a.c  testsuite/ld-elf/pr21964-2a.c
testsuite/ld-elf/pr21964-1b.c  testsuite/ld-elf/pr21964-2b.c
testsuite/ld-elf/pr21964-1c.c  testsuite/ld-elf/pr21964-2c.c

in binutils source tree?  They pass without Alan's patch.


-- 
H.J.