search for: pt_gnu_relro

...o give a pointer to another section which is writable. It would be nice to have this functionality on other targets as well however. Right now many dynamic linkers do not support this layer of indirection so this can't happen by default, it must be an option. Currently .dynamic gets mapped to a PT_GNU_RELRO section. PT_GNU_RELRO sections are not shared between instances of a executable however. It would be a nice optimization to share the .dynamic section of an application where possible. In particular we would like to have this option for Fuchsia. Other dynamic linkers, like musl, already have some s...

...which is writable. It would be nice to have this >> functionality on other targets as well however. Right now many dynamic >> linkers do not support this layer of indirection so this can't happen by >> default, it must be an option. Currently .dynamic gets mapped to a >> PT_GNU_RELRO section. PT_GNU_RELRO sections are not shared between >> instances of a executable however. It would be a nice optimization to share >> the .dynamic section of an application where possible. In particular we >> would like to have this option for Fuchsia. Other dynamic linkers, lik...

...ice to have this >>>> functionality on other targets as well however. Right now many dynamic >>>> linkers do not support this layer of indirection so this can't happen by >>>> default, it must be an option. Currently .dynamic gets mapped to a >>>> PT_GNU_RELRO section. PT_GNU_RELRO sections are not shared between >>>> instances of a executable however. It would be a nice optimization to share >>>> the .dynamic section of an application where possible. In particular we >>>> would like to have this option for Fuchsia. Ot...

It is the intention that .openbsd.randomdata sections are made read-only after initialization. The native (ld.bfd based) OpenBSD toolchain accomplishes this by including .openbsd.randomdata into the PT_GNU_RELRO segment. The diff below makes ldd do the same. Index: ELF/Writer.cpp =================================================================== --- ELF/Writer.cpp (revision 290066) +++ ELF/Writer.cpp (working copy) @@ -504,7 +504,7 @@ return true; StringRef S = Sec->getName(); return S ==...

...1:48 PM, Mark Kettenis via llvm-dev < llvm-dev at lists.llvm.org> wrote: > It is the intention that .openbsd.randomdata sections are made > read-only after initialization. The native (ld.bfd based) OpenBSD > toolchain accomplishes this by including .openbsd.randomdata into the > PT_GNU_RELRO segment. The diff below makes ldd do the same. > > Index: ELF/Writer.cpp > =================================================================== > --- ELF/Writer.cpp (revision 290066) > +++ ELF/Writer.cpp (working copy) > @@ -504,7 +504,7 @@ > return true; >...

...merged RELRO segment. > > For huge executables (>2G or 3G), it may cause relocation overflows > between .text and .rodata if other large sections like .dynsym and .dynstr > are > placed in between. > > I do not worry too much about overflows potentially caused by moving > PT_GNU_RELRO around. PT_GNU_RELRO is usually less than 10% of the size of > the > RX PT_LOAD. > That's good to know! > > > This would be a somewhat tedious change (especially the part about having > > to update all the unit tests), but the benefit is pretty good, especially > &g...

On Thu, Aug 29, 2019 at 3:10 AM Fāng-ruì Sòng <maskray at google.com> wrote: > Hello Vic, > > To make sure I understand the proposal correctly, do you propose: > > Old: R RX RW(RELRO) RW > New: R(R+RELRO) RX RW; R includes the traditional R part and the > RELRO part > Runtime (before relocation resolving): RW RX RW > Runtime (after relocation resolving): R RX

I've noticed that lld keeps the data section more isolated than the gold or bfd linkers. For example, readelf -l applied to the "same" executable linked with those three linkers reveals the following under "Section to Segment mapping": lld: 05 .data .got.plt .bss gold: 03 .eh_frame .init_array .fini_array .preinit_array .dynamic .got .got.plt .data .bss bfd: 05

...;>> functionality on other targets as well however. Right now many dynamic >>>>>> linkers do not support this layer of indirection so this can't happen by >>>>>> default, it must be an option. Currently .dynamic gets mapped to a >>>>>> PT_GNU_RELRO section. PT_GNU_RELRO sections are not shared between >>>>>> instances of a executable however. It would be a nice optimization to share >>>>>> the .dynamic section of an application where possible. In particular we >>>>>> would like to have thi...