Re: [PATCH v3 2/2] elf: Add GNU_PROPERTY_1_NEEDED check

[Florian Weimer <fweimer@redhat.com>]

* H. J. Lu:

>> Should the property be used just for error checking?  We would flip the
>> default unconditionally.  Such a behavioral change simply based on some
>> input file is quite surprising.
>
> The property is used to to allow compiling sources with
> -fno-direct-extern-access
> by pieces.  When creating a shared library, if one input relocatable file
> is compiled with -fno-direct-extern-access, linker will bind all protected
> symbols locally before seeing ALL relocations against them in different
> input relocatables files.

What is the advantage of this behavior?  Why should the presence of one
such object file in the link cause symbol binding behavior change
everywhere?  Especially if that one file does not even reference any
protected symbols?

>> For (4), I think we need to set a different flag (or perhaps even
>> flags), and be really careful about what we do.  I think an output file
>> that is an executable will never require indirect-extern-access, but it
>
> What did you mean by that?  We need to compile executable with
> -fno-direct-extern-access for the whole scheme to work.

indirect-extern-access imposes a requirement on executables, but
building an executable to comply with the new requirements will not
impose anything on the rest of the link.  I do not see the markup
covering that.

>> can be incompatible with indirect-extern-access objects at run time.
>> Shared objects as output files may themselves depend on
>> indirect-extern-access objects at run time.  Ideally, markup would be
>> applied to the relocations that are affected by the changes in the ABI.
>
> That is what my glibc changes do:
>
> $ ./elf/tst-protected1a
> ./elf/tst-protected1a: protected1:
> /export/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/tst-protected1moda.so:
> copy relocation against non-copyable protected symbol
> $ readelf -r ./elf/tst-protected1a | grep COPY
> 0000004071d8  004300000005 R_X86_64_COPY     00000000004071d8 protected1 + 0
> 0000004071dc  004600000005 R_X86_64_COPY     00000000004071dc protected3 + 0
>
> This error happens only if there is a copy relocation against protected symbol
> definition compiled with -fno-direct-extern-access.

Does this mean that executables do not need any markup at all, and that
looking at the relocation types is sufficient?  (Same for canonical
function addresses.)

Thanks,
Florian