[MIPS] Why is PT_DYNAMIC marked as PF_W (write)?

[MIPS] Why is PT_DYNAMIC marked as PF_W (write)?

[Jack Carter]

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.

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. 

Thanks,

Jack

Re: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?

[Cary Coutant]

> 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

RE: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?

[Jack Carter]

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

Re: [MIPS] Why is PT_DYNAMIC marked as PF_W (write)?

[Richard Sandiford]

Jack Carter <Jack.Carter@imgtec.com> writes:
> 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;
>         }
>     }

This code comes from f7cb7d68c22ad9334ead499c25008d107906b891.
I don't know why it was added either but:

    https://sourceware.org/ml/binutils/2000-05/msg00053.html

suggests it might have been for mips-dde-sysv4.2MP.

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

Yeah, I think we can drop the code you quoted.

Thanks,
Richard