[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