[PATCH v2] elf: Add optimization barrier for __ehdr_start and _end
Florian Weimer
fweimer@redhat.com
Mon Jun 16 07:02:30 GMT 2025
* Jakub Jelinek:
> On Mon, Jun 16, 2025 at 08:31:24AM +0200, Florian Weimer wrote:
>> >> It doesn't say why "g" is the appropriate constraint here.
>> >
>> > "+g" is the least restricted constraint. It tells compilers that the
>> > operand is both input and output.
>>
>> If it's least restricted, why can't this trigger the use of a vector
>> register? It seems to increase the risk of the bug happening, not
>> suppress it.
>
> The question is on what it is used. Either "+r" is used on the value of the
> address before storing it into memory, that ensures the address is loaded
> into a register first and then the register is later stored into memory,
> possibly vectorized.
> The other option is to break the vectorization by adding a read/write
> optimization barrier in between the two stores into memory, what the patch
> does (though because _dl_rtld_map.l_whatever is certainly in memory, I think
> using "=m" (_dl_rtld_map.l_whatever) : "m" (_dl_rtld_map.l_whatever)
> might be clearer; or even the whole _dl_rtld_map). That will prevent the
> vectorization, each store has to be done separately, so no vectorization
> of the two adjacent stores is possible.
Hmm. The "m" approach is not great for use in initializers (as in: it
is incompatible with it), like the rvf case I mentioned elsewhere in the
thread. The "+r" approach would work with initializers.
It should be properly macroized, unless we think that most
!HIDDEN_VAR_NEEDS_DYNAMIC_RELOC architecture can exhibit similar bugs
around the initialization of pointer members.
Thanks,
Florian
More information about the Libc-alpha
mailing list