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

[Peter Smith via Phabricator via llvm-commits]

peter.smith added a comment.

Thanks for the update. I'll put my comments here as I did a bit more digging into ld.bfd's orphan placement section. At a high-level It looks like they have anchor sections with known flags that orphans are placed after. In particular:

  .text
  .rodata
  .tdata
  .data
  .bss
  .interp
  .sdata
  .comment

It does not consider relro at all. So `.dynamic` is matched against `.data` and is placed afterwards. This makes the linker script assign two program headers but turns off RELRO.

I think that this makes sense given the definition of PHDRS as it says only generate PHDRS explicitly specified and this doesn't include PT_DYNAMIC or PT_GNU_RELRO. ld.bfd does not even accept PT_GNU_RELRO and at least the version of bfd I've got installed crashes when I use its numeric value.

I think to support RELRO we'd need something like:

  PHDRS {
    exec PT_LOAD;
    rw   PT_LOAD;
    dynamic PT_DYNAMIC;
    relro 1685382482;
  }
  SECTIONS {
    .text 0x8000 : { *(.text) } : exec
    .dynamic : { *(.data) } : rw : dynamic : relro
    .data : { *(.data) } : rw
  }

I've not got a great answer for what we ought to do. It seems like relro + PHDRS is not supported well right now with BFD. In that case I think we could do one of:

- Disable RELRO if there is a PT_PHDRS command, this would make .dynamic sort behind .data and avoid other attempts at creating relro.
- Add support for a PT_GNU_RELRO program header and require this before enabling relro. User will have to be quite explicit about what parts go into it though.

If we do one of these then I think the desired behaviour should drop out from your example linker script.


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

https://reviews.llvm.org/D111137