This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]