[PATCH] ELF: Properly handle section symbols

[H.J. Lu]

On Wed, Jun 10, 2020 at 7:14 AM Alan Modra <amodra@gmail.com> wrote:
>
> On Wed, Jun 10, 2020 at 06:29:58AM -0700, H.J. Lu wrote:
> > On Wed, Jun 10, 2020 at 6:27 AM Michael Matz <matz@suse.de> wrote:
> > >
> > > Hello,
> > >
> > > On Wed, 10 Jun 2020, Alan Modra via Binutils wrote:
> > >
> > > > > 1. Treat the common symbol, __start_FOO, in input object file as
> > > > > definition.
> > > > > 2. Clear verinfo.verdef.
> > > >
> > > > The above looks good.
> > > >
> > > > > 3. Make the section symbol PROTECTED only in shared library.
> > > >
> > > > I would be inclined to not make this change.  While it is true that
> > > > protected visibility only makes sense in a shared library, I can't see
> > > > a compelling reason to prohibit such a symbol in an executable.  I
> > > > made the comment in the bugzilla
> > > > "But that leaves you with a really odd
> > > >      5: 0000000000004010     8 OBJECT  GLOBAL PROTECTED   24 __start_FOO@@SOME_VERSION_NAME
> > > > in main."
> > > > because it seemed to me that this symbol being dynamic in the
> > > > executable serves no purpose.
> > >
> > > dlsym on these symbols has to work even on the main executable, so they
> > > have to be dynamic.  (Well, in the cases I met only those that are created
> > > by the linker, not the situation H.J. deals with here, but still)
> > >
> > > "has to work" is of course too strong, but the section symbols are
> > > special enough that we should assume usage of dlsym even without
> > > --export-dynamic, as we can't rule out such usage and the existence of
> > > them indicates that the user probably wants to access them somehow.
> > >
> > > (I think the library/appliction that sent me down this whole rabbit hole
> > > (pacemaker) is meanwhile changed to not rely on start/stop symbols
> > > anymore, but I don't see why someone else shouldn't have the same idea of
> > > usage)
> > >
> >
> > For that particular testcase, __start_FOO is referenced from the shared
> > library.
>
> Sure, I understand that case, but here we have a __start_FOO defined
> in the executables with a value proper for the executable, but with a
> version and visibility from the shared library.  The protected
> visibility in the shared library means that that particular library
> won't use the symbol from the executable.  And, why would any other
> shared library that might be dlopened want to use a SOME_VERSION_NAME
> versioned symbol for __start_FOO in the executable?

Linker ignores PROTECTED on shared library since share library at
link-time != share library at run-time.  The shared library at run-time
may not have PROTECTED.


-- 
H.J.