This is the mail archive of the
mailing list for the binutils project.
Re: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?
- From: Cary Coutant <ccoutant at google dot com>
- To: Jack Carter <Jack dot Carter at imgtec 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 13:41:21 -0800
- 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>
> 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
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.)