[PATCH] ELF: Properly handle section symbols

[Alan Modra]

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?

-- 
Alan Modra
Australia Development Lab, IBM