Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

[Michael Matz <matz@suse.de>]

Hello,

On Tue, 22 Jun 2021, H.J. Lu wrote:

> > > 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.

Like a binary that's working today will fail tomorrow if the updated 
shared lib simply removes a symbol from it's export without proper 
versioning.  I don't see a material difference.

> > 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.

I don't see why the address should matter.  My point was that in the end 
the exported symbol table for such shared lib (where foobar was changed 
from default to protected visiblity) should have

 1: 12345 42 FUNC GLOBAL DEFAULT 1 foobar@Old
 2: 12345 42 FUNC GLOBAL PROTECTED 1 foobar@@New

This might require new GAS directives and compiler attributes (or might be 
expressible already).  References from within the shared library would 
need to continue going via the default visiblity symbol, so that it 
supports old binaries containing copy relocs, which just again points out 
that it's a bad idea to restrict visibility after the fact.

AFAICS your scheme also doesn't support old binaries with newly protected 
symbols in newer shared libs, so an (unconditional) error in such 
situation seems appropriate.  IOW: which scenario do you want to not error 
on when you want to make the error conditional?


Ciao,
Michael.