[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[H.J. Lu via llvm-dev]

On Mon, Jun 21, 2021 at 7:36 AM Michael Matz <matz at suse.de> wrote:
>
> Hello,
>
> On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote:
>
> > > > • Disallow copy relocation against definition with the STV_PROTECTED
> > > > visibility in the shared library with the marker.
> > >
> > > If this is for GNU ld x86 only, I'm fine with it:)
> > >
> > > gold and ld.lld just emit an error unconditionally. I think non-x86
> > > GNU ld ports which never support "copy relocations on protected data
> > > symbols" may want to make the diagnostic unconditional as well.
> > > Well, while (Michael Matz and ) I think compatibility check for "copy
> > > relocations on protected data symbols" is over-engineering (and
> > > Alan/Cary think it was a mistake), if you still want to add it, it is
> > > fine for me...
> > > For Clang, I hope we will not emit such a property, because Clang
> > > never supports the "copy relocations on protected data symbols"
> > > scheme.
> >
> > The issue is that libfoo.so used in link-time can be different from
> > libfoo.so at run-time.  The symbol, foobar, in libfoo.so at link-time
> > has the default visibility.  But foobar in libfoo.so at run-time can be
> > protected.  ld.so should detect such cases which can lead to run-time
> > failures.
>
> Yes, but I think we can _unconditionally_ give an error in this case, even
> without a marker.  I view restricting visiblity of a symbol in furture

Unconditionally issuing an error can be an option, but mandatory.
Otherwise working binary today will fail to run tomorrow.

> versions of shared libraries to be an ABI change, hence it has to be
> something that either requires a soname bump or at the very least symbol

To support existing binaries, we need a soname bump.

> versioning with the old version staying on default visibility.

Symbol versioning doesn't work here since both symbols are at
the same address.

> Compare the situation to one where the old libfoo.so provided a symbol
> bar, and the new one doesn't (sort of very restricted visiblity).  ld.so
> will unconditionally give an error.  I don't see this situation materially
> different from bar's visibility be changed from default to protected.
>
> > > I think this can be unconditional, because the "pointer equality for
> > > STV_PROTECTED function address in -shared" case hasn't been working
> > > for GNU ld for at least 20 years... Many ports don't even produce a
> > > dynamic relocation.
> >
> > True.  But see above.  You may not care about such use cases.  But I
> > believe that ld.so should not knowingly and silently allow such run-time
> > failure to happen.
>
> Agreed, but giving an error message unconditionally wouldn't be silent.
>
>
> Ciao,
> Michael.



-- 
H.J.