[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