[PATCH] elf: Support multiple PT_GNU_RELRO segments

[Adhemerval Zanella Netto]

On 07/07/26 15:17, Justin Rivera wrote:
> On Mon, Jul 6, 2026 at 5:15 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>
>> On Tue, Jul 7, 2026 at 5:11 AM Justin Rivera <jnrivera@google.com> wrote:
>>>
>>> Hello,
>>>
>>> While this patch appears to be working as intended, I had a question
>>> regarding any additions to the test suite for testing RELRO behavior.
>>>
>>> This patch modifies elf/tst-relro-symbols.py, which can statically check
>>> ELF headers. However, there don't seem to be any dynamic checks that would
>>> work for multiple RELRO segments. We were able to do some ad-hoc testing
>>> with some hand-written assembly, but getting something working within the
>>> test suite seemed to be a bit trickier. (Often ran into
>>> `/usr/bin/ld: foo.so: warning: unable to allocate any sections to PT_GNU_RELRO segment`
>>> without some additional patching hack, for example).
>>>
>>> Are there any suggestions on how to best test the behavior changed by this patch?
>>
>> We should add the linker support first.  Linker can have an option
>> to generate multiple PT_GNU_RELRO segments for small binaries.
>>
>>
>> H.J.
> 
> Hi,
> 
> Could you provide some more details regarding adding linker support?
> If you could point me toward
> the right place in binutils as well, that'd help tons.
> 
> Also, just for additional context, we were able to test this change
> locally via a hand-written
> assembly ELF binary. We bypassed the GNU linker to emit an ELF file
> with two `PT_GNU_RELRO`
> segments, and used it to dynamically verify that the loader calls
> protects both segments. We proved
> this via a shell script that checks for segfaults when the binary
> attempts to illegally write to either protected segment.
> 
> Is this something that can be useful for the glibc test suite if
> cleaned up? Or would you prefer to hold
> off on this glibc patch entirely until explicit linker support is landed?

We already have scripts/tst-elf-edit.py which creates synthetic DSO with
different alignments, so a platform agnostic testing framework could work.

Is these hand-written assembly arch-specific or can you make them generic
(so we can test onany supported ABI)? 

One possibility is to create the tests (ET_EXEC/ET_DYN) with some extra dummy
DT_NEEDED tags by linking with -Wl,--as-needed and some libraries, and then 
post-processing it and replace it with PT_GNU_RELRO tags.

The mold linker has --spare-dynamic-tags=N, but unfortunately we can not rely
on it for testing.