Re: [PATCH v2] elf: Remove ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA

[Fangrui Song <maskray@google.com>]

On 2022-06-01, Florian Weimer wrote:
>* Szabolcs Nagy via Libc-alpha:
>
>> but that's not true: the exe (or a shared lib) can now
>> interpose a protected variable by another one with the
>> same name (and no copy relocs).
>
>That's not desirable at all, I think.  It's certainly very surprising.
>
>> i originally thought that warning/rejecting copy relocs in
>> ld is enough to get sane behaviour for protected symbols,
>> but when multiple definitions are present the behaviour
>> will depend on ld's decision to use GOT or not.
>>
>> i think the removed logic tried to ensure that GOT relocs
>> resolve to the definition within the same shared lib for
>> protected data. (i.e. ld's decision does not matter.)
>>
>> if we want to allow ld to not use GOT then i think we need
>> to keep the logic that makes GOT behave consistently with
>> that future.
>
>I agree.  I have this mental model that protected symbols behave like
>-Bsymbolic.  The ELF specification also seems to require that the symbol
>cannot be preempted.

Yes.  I just send two GNU ld patches (arm and aarch64) to restore the
previous behavior whether ld -shared produces RELATIVE instead of
GLOB_DAT for GOT-generating relocations referencing a protected data
symbol:
https://sourceware.org/pipermail/binutils/2022-June/