This is the mail archive of the 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)?

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.

From: Cary Coutant []
Sent: Tuesday, February 11, 2014 1:41 PM
To: Jack Carter
Cc:; 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

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.)


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