[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Michael Matz via llvm-dev]

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 
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 
versioning with the old version staying on default visibility.

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.