[PATCH] Mark __start/__stop symbols as PROTECTED in shared object

[H.J. Lu]

On Tue, Aug 15, 2017 at 6:48 PM, Alan Modra <amodra@gmail.com> wrote:
> On Tue, Aug 15, 2017 at 06:05:16PM -0700, H.J. Lu wrote:
>> On Tue, Aug 15, 2017 at 5:50 PM, Alan Modra <amodra@gmail.com> wrote:
>> > On Mon, Aug 14, 2017 at 05:10:02PM -0700, H.J. Lu wrote:
>> >> On Mon, Aug 14, 2017 at 4:53 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> >> > When building shared objects, mark __start and __stop symbols as
>> >> > PROTECTED and bind them as symbolic to support dlsym.  Also override
>> >> > __start, __stop, .startof.  and .sizeof. symbols defined in a shared
>> >> > object.
>> >> >
>> >> > OK for master?
>> >> >
>> >> > bfd/
>> >> >
>> >> > PR ld/21964
>> >> > * elf-bfd.h (SYMBOLIC_BIND): TRUE for __start/__stop symbols.
>> >> > * elflink.c (bfd_elf_define_start_stop): Override symbol defined
>> >> > in a shared object.  Mark __start/__stop symbols as PROTECTED in
>> >> > shared objects.
>> >> >
>> >>
>> >> No need to mark them as protected when bind them symbolic.
>> >
>> > I think you should be making these symbols protected visibility.
>> >
>>
>> The question is if they should be bound symbolically.  If no, is there
>> a use case? If yes, why PROTECTED?
>
> If these linker provided symbols are made protected visibility then
> that itself advertises their binding.  They bind locally within that
> binary.  If you change SYMBOLIC_BIND then that is a magic linker
> behaviour, not wrong, but not something that is obvious from the
> object file.

Those symbols are changed to non-hidden to support dlsym, nothing else.
Symbolic binding is perfect for this purpose.

> Incidentally, your patch is in response to a use case that was broken
> when you made them hidden in shared libraries.  I wonder whether they

And my change fixed a real issue as shown in the testcase in my
patch.

> shouldn't be protected in the executable too?  I can imagine a shared
> library needing access to a special section in the executable.

Since these symbols aren't unique, if relocation is involved, you
can't be sure where these symbols will be found at run-time.  The shared
library needs another way to access the section in the executable.

>

Here is the same patch with the updated testcase to verify that
these symbols are local to modules for different cases.

-- 
H.J.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Bind-__start-__stop-symbols-as-symbolic-in-shared-ob.patch
Type: text/x-patch
Size: 18017 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20170816/16fba532/attachment.bin>