[PATCH] D111137: [ELF] Propagate phdrs to orphan section with a smaller rank

Peter Smith via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Oct 11 08:47:09 PDT 2021


peter.smith added a comment.

Looking at GNU ld and the documentation for PHDRS https://sourceware.org/binutils/docs/ld/PHDRS.html

  If you place a section in one or more segments using ‘:phdr’, then the linker will place all subsequent allocatable sections which do not specify ‘:phdr’ in the same segments. This is for convenience, since generally a whole set of contiguous sections will be placed in a single segment. You can use :NONE to override the default segment and tell the linker to not put the section in any segment at all.

This would imply that if .dynamic were placed before .data, implicitly making the script

  PHDRS {
    exec PT_LOAD;
    rw   PT_LOAD;
  }
  SECTIONS {
    .text : { *(.text) } : exec
    .dynamic : { *(.dynamic) } /* No explicit program header, inherit from previous */
    .data : { *(.data) } : rw
  }

Then ld.bfd does what LLD does and makes the first program header writeable.

When trying the same example with ld.bfd I notice that it assigns .dynamic after .data when .dynamic is an orphan.

  .text           0x0000000000008000        0x1
   *(.text)
   .text          0x0000000000008000        0x1 orphan.o
  
  .plt            0x0000000000008010        0x0
   .plt           0x0000000000008010        0x0 orphan.o
  
  .plt.got        0x0000000000008008        0x0
   .plt.got       0x0000000000008008        0x0 orphan.o
  
  .interp         0x0000000000008001        0xf
   .interp        0x0000000000008001        0xf orphan.o
  
  .gnu.version_d  0x0000000000008010        0x0
   .gnu.version_d
                  0x0000000000008010        0x0 orphan.o
  
  .gnu.version    0x0000000000008010        0x0
   .gnu.version   0x0000000000008010        0x0 orphan.o
  
  .gnu.version_r  0x0000000000008010        0x0
   .gnu.version_r
                  0x0000000000008010        0x0 orphan.o
  
  .dynsym         0x0000000000008010       0x18
   .dynsym        0x0000000000008010       0x18 orphan.o
  
  .dynstr         0x0000000000008028        0x1
   .dynstr        0x0000000000008028        0x1 orphan.o
  
  .hash           0x0000000000008030       0x10
   .hash          0x0000000000008030       0x10 orphan.o
  
  .gnu.hash       0x0000000000008040       0x1c
   .gnu.hash      0x0000000000008040       0x1c orphan.o
  
  .eh_frame       0x0000000000008060        0x0
   .eh_frame      0x0000000000008060        0x0 orphan.o
   .eh_frame      0x0000000000008060        0x0 orphan.o
  
  .rela.dyn       0x0000000000008060        0x0
   .rela.plt      0x0000000000008060        0x0 orphan.o
   .rela.got      0x0000000000008060        0x0 orphan.o
   .rela.bss      0x0000000000008060        0x0 orphan.o
   .rela.data.rel.ro
                  0x0000000000008060        0x0 orphan.o
   .rela.ifunc    0x0000000000008060        0x0 orphan.o
  .data           0x000000000000805c        0x2
   *(.data)
   .data          0x000000000000805c        0x2 orphan.o
  OUTPUT(orphan elf64-x86-64)
  
  .dynamic        0x0000000000008060       0xe0
   .dynamic       0x0000000000008060       0xe0 orphan.o
                  0x0000000000008060                _DYNAMIC
  
  .got            0x0000000000008140        0x0
   .got           0x0000000000008140        0x0 orphan.o
  
  .got.plt        0x0000000000008140        0x0
   .got.plt       0x0000000000008140        0x0 orphan.o
  
  .data.rel.ro    0x0000000000008140        0x0
   .data.rel.ro   0x0000000000008140        0x0 orphan.o
  
  .dynbss         0x0000000000008140        0x0
   .dynbss        0x0000000000008140        0x0 orphan.o

To be consistent with ld.bfd would it be better to look at the orphan placement of .dynamic?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111137/new/

https://reviews.llvm.org/D111137



More information about the llvm-commits mailing list