[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
Michael Matz via llvm-dev
llvm-dev at lists.llvm.org
Mon Jun 21 07:35:58 PDT 2021
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
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.
More information about the llvm-dev