[llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED

Fangrui Song via llvm-dev llvm-dev at lists.llvm.org
Fri Jun 18 14:34:50 PDT 2021


On 2021-06-18, H.J. Lu via llvm-dev wrote:
>Add GNU_PROPERTY_1_NEEDED:
>
> #define GNU_PROPERTY_1_NEEDED      GNU_PROPERTY_UINT32_OR_LO
>
>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?

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

>Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION:
>
> #define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION  (1U << 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.

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.

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