llvm dev - Jun 2021 - RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

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.

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.