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.
