[PATCH] ld: Disable separate code by default for Linux/x86
Florian Weimer
fweimer@redhat.com
Tue Mar 17 16:45:45 GMT 2026
* H. J. Lu:
> On Tue, Mar 17, 2026 at 5:01 AM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * H. J. Lu:
>>
>> > On Mon, Mar 16, 2026 at 7:20 AM WANG Rui <r@hev.cc> wrote:
>> >>
>> >> Years ago, commit f6aec96dce1d ("ld: Add --enable-separate-code") introduced
>> >> -z separate-code, mainly to avoid mixing code and data in the same segment
>> >> for better cache performance, and enabled it by default for Linux/x86.
>> >
>> > -z separate-code reduces cache pollution and
>>
>> 64 byte section alignment would achieve the same thing, I believe.
>
> This avoids cacheline pollution, not cache pollution. icache can still
> contain read-only data and dcache can contain code.
Sorry, I still don't get it.
>> But maybe there's impact on TLB slots? But then separate-code seems to
>> make page coalescing more difficult.
>
>> > improves security by avoiding putting read-only data in the same page
>> > with code.
>>
>> I think we've moved on from gadget avoidance as a security hardening
>> approach, so I'm not sure that's relevant anymore.
>
> So gadget isn't a security issue anymore?
No, I don't think so.
>> > Should ld.so map read-only data segment plus code segment into the same huge
>> > page? This should have the similar effect as -z noseparate-code.
>>
>> Would it? Lots of objects have segments smaller than 2 MiB.
>
> Does THP help their performance? Won't -z noseparate-code be good for them?
I think you need fairly recent kernels for THP usage with non-anonymous
memory. THP should help. -z noseparate-code may lead to more page
coalescing opportunities because there are fewer and larger load
segments.
Thanks,
Florian
More information about the Libc-alpha
mailing list