This is the mail archive of the
mailing list for the binutils project.
Re: PT_GNU_RELRO flags
- From: jose dot marchesi at oracle dot com (Jose E. Marchesi)
- To: Alan Modra <amodra at gmail dot com>
- Cc: binutils at sourceware dot org, Mark Wielaard <mjw at redhat dot com>
- Date: Tue, 13 Oct 2015 14:12:40 +0200
- Subject: Re: PT_GNU_RELRO flags
- Authentication-results: sourceware.org; auth=none
- References: <87612gvv7r dot fsf at oracle dot com> <20151013060423 dot GJ4434 at bubble dot grove dot modra dot org>
> The thing is, eu-elflint checks precisely for that, and complains for
> shared objects linked with -zrelro:
> loadable segment  flags do not match GNU_RELRO  flags
> Was this change intended? Does it makes sense to have RELRO=R/LOAD=RWE
> pairs in elf files? (RELRO segments contain .plt sections in sparc, for
> example, and I would expect these to be executable...).
The change was intended to fix a problem with objcopy/strip when
making separate debug files from executables created by gold. I
don't think there was an intention to change the behaviour of ld.
However, I like the current GNU ld behaviour of setting PT_GNU_RELRO
p_flags to PF_R. Of any flag value I think that makes most sense
because that is the protection applied to the RELRO segment by glibc.
(See elf/dl-reloc.c:_dl_protect_relro.) Some larger PT_LOAD segment
covering the same addresses might indeed be PF_X, but I don't see that
The smaller PT_GNU_RELRO segment does not contain executable
sections. (You're wrong in your claim that RELRO segments contain
.plt sections in sparc binaries. They don't. The RELRO segment
finishes just before .plt.)
Ugh, right. I misread the output of readelf -l. Well, I agree: it
makes all sense to have the same perms that are applied later by the
dynamic loader, and E is not needed.
Time to update the elfutils test.