[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
Tue Jun 22 07:54:47 PDT 2021
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 at 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?
More information about the llvm-dev