search for: d56828

...oss-DSO CFI implementation in Android needed to be updated, could that also be the case on other platforms? - Does this need work in every OS to take advantage of it? For example would this need a ld.so change on Linux? The last time we updated the position of RELRO was in https://reviews.llvm.org/D56828 it will be worth going through the arguments in there to see if there is anything that triggers any thoughts. Peter On Thu, 29 Aug 2019 at 09:22, Rui Ueyama <ruiu at google.com> wrote: > > Hi Vic, > > I'm in favor of this proposal. Saving that amount of kernel memory by chan...

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

Hey all, TL;DR: Moving RELRO segment to be immediately after read-only segment so that the dynamic linker has the option to merge the two virtual memory areas at run time. This is an RFC for moving RELRO segment. Currently, lld orders ELF sections in the following order: R, RX, RWX, RW, and RW contains RELRO. At run time, after RELRO is write-protected, we'd have VMAs in the order of: R, RX,

...to be updated, could that also be the case on other platforms? >> - Does this need work in every OS to take advantage of it? For example >> would this need a ld.so change on Linux? >> >> The last time we updated the position of RELRO was in >> https://reviews.llvm.org/D56828 it will be worth going through the >> arguments in there to see if there is anything that triggers any >> thoughts. >> >> Peter >> >> On Thu, 29 Aug 2019 at 09:22, Rui Ueyama <ruiu at google.com> wrote: >> > >> > Hi Vic, >> > >...