Re: [PATCH v2 0/2] elf: Implement indirect external access marker

[Fangrui Song <i@maskray.me>]

On 2021-07-07, Florian Weimer via Binutils wrote:
>* H. J. Lu:
>
>> On Wed, Jul 7, 2021 at 7:01 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * H. J. Lu:
>>>
>>> > I am checking in this patch by the end of this week.
>>>
>>> Shouldn't the ABI specification be finalized first?  (Sorry.)
>>>
>>
>> Did you mean adding GNU_PROPERTY_1_NEEDED_INDIRECT_EXTERN_ACCESS?
>> I have submitted linker, GCC and glibc patches to show how it is used.
>>
>> To see how it works, we need to start with a working linker.  That is
>> why I want to add it to the linker now.
>
>Hmm, I see.  I guess it's up to the binutils maintainers to decide.
>
>Thanks,
>Florian
>

Seems that the motivation is GNU ld internals
https://sourceware.org/pipermail/binutils/2021-June/117132.html
If so, I am fine with this GNU property (but I will not recommend it within llvm-project).

---

I hope glibc's diagnostic on "rejecting copy relocations on protected data symbol"
can be unconditional, not check this GNU property.

Here https://lists.llvm.org/pipermail/llvm-dev/2021-June/151248.html 
I investigated many binutils versions (2.11, 2.16, 2.20, 2.24, 2.35).
They have the same diagnostic

   relocation R_X86_64_PC32 against protected function `addr' can not be used when making a shared object

for

   // protected data is similar
   __attribute__((visibility("protected"))) void *addr() { return (void*)addr; }

so we should just assume protected definitions never works and don't
bother with gnu property complexity in glibc.