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

[H.J. Lu]

On Mon, Jan 29, 2018 at 6:18 PM, Alan Modra <amodra@gmail.com> wrote:
> On Mon, Jan 29, 2018 at 05:17:10PM -0800, H.J. Lu wrote:
>> On Mon, Jan 29, 2018 at 4:50 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Mon, Jan 29, 2018 at 04:39:15PM -0800, H.J. Lu wrote:
>> >> +extern int __start___verbose[];
>> >> +extern int __stop___verbose[];
>> >> +int
>> >> +foo3 (void)
>> >> +{
>> >> +  if (__start___verbose == __stop___verbose
>> >> +      || __start___verbose[0] != 6)
>> >> +    return -1;
>> >> +  else
>> >> +    return 0;
>> >> +}
>> >>
>> >> Which __start___verbose/_start___verbose definition should it
>> >> reference at run-time? There are more than one.
>> >
>> > They should be resolved as for any other symbol in an ELF shared
>> > library.  The test is verifying that we don't resolve to
>> > __start/__stop symbols in another shared library's __verbose section
>> > if there is a __verbose section in the executable.
>> >
>>
>> Can you add another testcase with -Wl,--gc-sections on executable?
>
> Do you suspect something goes wrong with --gc-sections?  With the

I hope not.  A test is reassuring.  We had quite some issues with --gc-sections
and __start/__stop symbols before.

> latest test the dynamic reference from the shared library stops
> --gc-sections removing the __verbose section.  I don't think that is
> wrong as it is the same behaviour as for any other symbol defined in a
> section.
>


-- 
H.J.