This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
RE: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?
- From: Jack Carter <Jack dot Carter at imgtec dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: "binutils at sourceware dot org" <binutils at sourceware dot org>, Chris Dearman <Chris dot Dearman at imgtec dot com>
- Date: Tue, 11 Feb 2014 22:35:14 +0000
- Subject: RE: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?
- Authentication-results: sourceware.org; auth=none
- References: <4CEFBC1BE64A8048869F799EF2D2EEEE4C6F3F90 at BADAG02 dot ba dot imgtec dot org>,<CAHACq4o9fr6gTMLPDp=Wg9Msyn1LYL_U480NoXi+8pkFiXzQZg at mail dot gmail dot com>
Somewhere in my sordid past I remember something about wanting to get to some of the information in the dynamic sections real early, at the same read as getting the ELF header. That would be an SGI IRIX ism and wouldn't necessarily apply to other GNU targets such as LINUX. If this is not needed, I would want to move the dynamic sections to the data segment and change the flag bits.
If the flags can represent at least a subset of the underlying PT_LOAD segment it would be good. Even if it means for them not having flag bits if they are not PT_LOAD.
Jack
________________________________________
From: Cary Coutant [ccoutant@google.com]
Sent: Tuesday, February 11, 2014 1:41 PM
To: Jack Carter
Cc: binutils@sourceware.org; Chris Dearman
Subject: Re: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?
> It looks like the segment flag bits are hard coded to read write execute no matter where they are located. Why is this not a bug? This is for non-IRIX bits.
I have no idea why PF_X is set for mips. Normally, the .dynamic
section would have SHF_WRITE, which makes it part of the data segment,
and the PT_DYNAMIC segment would point to that portion of the data
segment.
In the subject line, you ask why it's PF_W. That's because many of the
values in the dynamic table are relocatable addresses, and this allows
the dynamic linker to relocate the values in place. Some platforms
also have vendor-specific dynamic table entries for things like
debugging that require the entries to be writable.
> Traditionally the .dynamic section/segment resides in the text segment, but wherever it gets located the flags are hardcoded as below:
>
> if (m != NULL && IRIX_COMPAT (abfd) == ict_none)
> {
> /* For a normal mips executable the permissions for the PT_DYNAMIC
> segment are read, write and execute. We do that here since
> the code in elf.c sets only the read permission. This matters
> sometimes for the dynamic linker. */
> if (bfd_get_section_by_name (abfd, ".dynamic") != NULL)
> {
> m->p_flags = PF_R | PF_W | PF_X;
> m->p_flags_valid = 1;
> }
> }
>
> Are there special rules for segments that are not PT_LOAD?
>
> If this is obsolete for Mips, can I fix it to match the PT_LOAD segment it overlays? ;-) The "This matters sometimes for the dynamic linker" is probably part of the answer, but I haven't found it yet.
I can't think of any reason why a non-LOAD segment that overlays a
LOAD segment shouldn't have the same flags as the LOAD segment.
Technically, though, I don't think that the segment permissions bits
in p_flags have any meaning except for LOAD segments. (There may be,
in some cases, vendor-specific bits in p_flags that do have meaning
for non-LOAD segments.)
-cary