This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: PT_GNU_RELRO flags
- From: Alan Modra <amodra at gmail dot com>
- To: "Jose E. Marchesi" <jose dot marchesi at oracle dot com>
- Cc: binutils at sourceware dot org, Mark Wielaard <mjw at redhat dot com>
- Date: Tue, 13 Oct 2015 16:34:23 +1030
- Subject: Re: PT_GNU_RELRO flags
- Authentication-results: sourceware.org; auth=none
- References: <87612gvv7r dot fsf at oracle dot com>
On Fri, Oct 09, 2015 at 06:54:16PM +0200, Jose E. Marchesi wrote:
>
> Hi hackers! The following commit:
>
> commit 2d16d28e5c20aacc9637f589558c118d6fe1a17c
> Author: Doug Kwan <dougkwan@google.com>
> Date: Tue May 8 17:18:21 2012 +0000
>
> 2012-05-08 Ben Cheng <bccheng@google.com>
>
> * bfd/elf.c: Preserve the original p_align and p_flags if they
> are valid.
>
> Makes ld to not derive the PT_GNU_RELRO segment flags from its covering
> PT_LOAD segment when it already contains "valid" flags (bfd creates them
> with "R" flags, whereas gold creates them with "RW"). As a result, it
> is no longer generally true that `RELRO->p_flags & ~PF_W ==
> LOAD->p_flags & ~PF_W'.
>
> The thing is, eu-elflint checks precisely for that, and complains for
> shared objects linked with -zrelro:
>
> loadable segment [5] flags do not match GNU_RELRO [1] 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
being relevant. 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.)
I'm committing the following to make it clear that ld now sets
PT_GNU_RELRO p_flags to PF_R. It's not a functional change, just a
tidy.
* elf.c (_bfd_elf_map_sections_to_segments): Don't set
PT_GNU_RELRO p_flags.
(assign_file_positions_for_non_load_sections): Set PT_GNU_RELRO
flags to PF_R here.
diff --git a/bfd/elf.c b/bfd/elf.c
index 6c878bd..7f38fa0 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -4646,9 +4646,6 @@ _bfd_elf_map_sections_to_segments (bfd *abfd, struct bfd_link_info *info)
goto error_return;
m->next = NULL;
m->p_type = PT_GNU_RELRO;
- m->p_flags = PF_R;
- m->p_flags_valid = 1;
-
*pm = m;
pm = &m->next;
}
@@ -5480,7 +5477,7 @@ assign_file_positions_for_non_load_sections (bfd *abfd,
if (!m->p_align_valid)
p->p_align = 1;
if (!m->p_flags_valid)
- p->p_flags = (lp->p_flags & ~PF_W);
+ p->p_flags = PF_R;
}
else
{
--
Alan Modra
Australia Development Lab, IBM