H.J. Lu via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 18 18:09:42 PDT 2021

On Fri, Jun 18, 2021 at 2:34 PM Fangrui Song <maskray at google.com> wrote:
> On 2021-06-18, H.J. Lu via llvm-dev wrote:
> >
> >
> >to indicate the needed properties by the object file.
> >
> I am fine with this logical OR style usage. But see below, do we need it
> for ld.so runtime check?

I implemented run-time check on users/hjl/single-global/master branch:


with tests:

[hjl at gnu-cfl-2 build-x86_64-linux]$ elf/tst-protected1a
copy relocation against non-copyable protected symbol=protected1 in
[hjl at gnu-cfl-2 build-x86_64-linux]$ elf/tst-protected2a
`protected1' in main and moda doesn't have the same address
non-canonical reference to canonical protected function
symbol=protected1 in
[hjl at gnu-cfl-2 build-x86_64-linux]$

I prefer these over random run-time failures.

> (As I mentioned previously, I do not know how an AND-style property can
> be used/deployed if old object files without the .note.gnu.property is
> considered to have a value of 0.)
> >
> >
> >to indicate that the object file requires canonical function pointers and
> >cannot be used with copy relocation.
> In https://sourceware.org/pipermail/gnu-gabi/2021q2/000481.html you gave
> a rationale
> "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."
> First, I think such dynamic symbol visibility change is uncommon.

I can imagine that some libraries want to switch to protected symbols.

> Second, if ld.so finds that a symbol lookup for (st_value==0
> st_shndx==SHN_UNDEF) will bind to a STV_PROTECTED definition in a shared
> object, can the diagnostic be moved there?
> The compatibility property is per-symbol and the symbol lookup is a
> perfect place for a diagnostic, like a symbol versioning error.
> I guess GCC folks may get noticed if you start a thread adding
> -fsingle-global-definition, otherwise many people who have opinions may
> just ignore threads about GNU PROPERTY addition.

Binutils changes are at


GCC changes are next.

> >
> >The PDF file is at
> >
> >https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/9eca2f2defe62b0c5015bf2e3e8a9f05/Linux-gABI-1_needed-2021-06-18.pdf


More information about the llvm-dev mailing list