Jake Ehrlich via llvm-dev
2017-May-16 23:31 UTC
[llvm-dev] [lld][ELF] Add option to make .dynamic read only
Hi, This is a proposal to add an option to lld that forces .dynamic sections to be read-only. The .dynamic section is almost read-only except for the DT_DEBUG entry which requires the dynamic linker to modify a word. MIPS has long since had a solution to this using the DT_MIPS_RLD_MAP entry to 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 support for this on non-MIPS targets as seen here: http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1629. In particular the DT_DEBUG_INDIRECT entry is recognized. This change would refactor code that already exists for MIPS specific .dynamic sections and make them available to other targets. Mostly this would just require renaming some things and moving a few lines around. The biggest part of this change would be to add the flag. I propose it be a -z keyword called "rodynamic". I have already made a patch for this change which can be seen here: https://reviews.llvm.org/D33251 Best, Jake -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170516/710a1200/attachment.html>
Rui Ueyama via llvm-dev
2017-May-17 00:13 UTC
[llvm-dev] [lld][ELF] Add option to make .dynamic read only
Hi Jake, Thank you for sending this to llvm-dev! If I understand correctly, your motivation to add an option to make .dynamic sections read-only is to share .dynamic sections in memory so that each process executing the same file doesn't have to have a separate copy of a .dynamic section. But you would usually save just one page or two by doing that because .dynamic sections are usually very small. Even if they are large, they could be shared between processes by copy-on-write. What am I missing? On Tue, May 16, 2017 at 4:31 PM, Jake Ehrlich via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > This is a proposal to add an option to lld that forces .dynamic sections > to be read-only. > > The .dynamic section is almost read-only except for the DT_DEBUG entry > which requires the dynamic linker to modify a word. MIPS has long since had > a solution to this using the DT_MIPS_RLD_MAP entry to 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 support for this on non-MIPS targets as seen here: > http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1629. In > particular the DT_DEBUG_INDIRECT entry is recognized. > > This change would refactor code that already exists for MIPS specific > .dynamic sections and make them available to other targets. Mostly this > would just require renaming some things and moving a few lines around. The > biggest part of this change would be to add the flag. I propose it be a -z > keyword called "rodynamic". > > I have already made a patch for this change which can be seen here: > https://reviews.llvm.org/D33251 > > Best, > Jake > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170516/a5a82635/attachment.html>
Jake Ehrlich via llvm-dev
2017-May-17 01:08 UTC
[llvm-dev] [lld][ELF] Add option to make .dynamic read only
Your understanding is correct. It saves a small number of physical pages. It's strictly better even if it's only a little bit better. On Tue, May 16, 2017, 5:14 PM Rui Ueyama <ruiu at google.com> wrote:> Hi Jake, > > Thank you for sending this to llvm-dev! > > If I understand correctly, your motivation to add an option to make > .dynamic sections read-only is to share .dynamic sections in memory so that > each process executing the same file doesn't have to have a separate copy > of a .dynamic section. But you would usually save just one page or two by > doing that because .dynamic sections are usually very small. Even if they > are large, they could be shared between processes by copy-on-write. What am > I missing? > > On Tue, May 16, 2017 at 4:31 PM, Jake Ehrlich via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> This is a proposal to add an option to lld that forces .dynamic sections >> to be read-only. >> >> The .dynamic section is almost read-only except for the DT_DEBUG entry >> which requires the dynamic linker to modify a word. MIPS has long since had >> a solution to this using the DT_MIPS_RLD_MAP entry to 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 support for this on non-MIPS targets as seen here: >> http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1629. In >> particular the DT_DEBUG_INDIRECT entry is recognized. >> >> This change would refactor code that already exists for MIPS specific >> .dynamic sections and make them available to other targets. Mostly this >> would just require renaming some things and moving a few lines around. The >> biggest part of this change would be to add the flag. I propose it be a -z >> keyword called "rodynamic". >> >> I have already made a patch for this change which can be seen here: >> https://reviews.llvm.org/D33251 >> >> Best, >> Jake >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170517/0e5e29f7/attachment.html>
Rafael Avila de Espindola via llvm-dev
2017-May-18 17:15 UTC
[llvm-dev] [lld][ELF] Add option to make .dynamic read only
Jake Ehrlich via llvm-dev <llvm-dev at lists.llvm.org> writes:> Hi, > > This is a proposal to add an option to lld that forces .dynamic sections to > be read-only. > > The .dynamic section is almost read-only except for the DT_DEBUG entry > which requires the dynamic linker to modify a word. MIPS has long since had > a solution to this using the DT_MIPS_RLD_MAP entry to 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 support for this on non-MIPS targets as seen here: > http://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c#n1629. In particular > the DT_DEBUG_INDIRECT entry is recognized.Actually, that is just a nice name they use. It is only defined to non zero in arch/mips/reloc.h:#define DT_DEBUG_INDIRECT DT_MIPS_RLD_MAP arch/mips64/reloc.h:#define DT_DEBUG_INDIRECT DT_MIPS_RLD_MAP arch/mipsn32/reloc.h:#define DT_DEBUG_INDIRECT DT_MIPS_RLD_MAP so it is still mips only. Also, according to https://sourceware.org/ml/binutils/2014-02/msg00073.html The idea of having .dynamic be RW is that the .d_ptr fields can be relocated. Not sure if any dynamic linker actually does it, but we should check.> This change would refactor code that already exists for MIPS specific > .dynamic sections and make them available to other targets. Mostly this > would just require renaming some things and moving a few lines around. The > biggest part of this change would be to add the flag. I propose it be a -z > keyword called "rodynamic". > > I have already made a patch for this change which can be seen here: > https://reviews.llvm.org/D33251The main issue if that you cannot reuse the mips specific flag value. If you want something architecture independent you need a new flag. Cheers, Rafael
Joerg Sonnenberger via llvm-dev
2017-May-20 11:22 UTC
[llvm-dev] [lld][ELF] Add option to make .dynamic read only
On Tue, May 16, 2017 at 11:31:13PM +0000, Jake Ehrlich via llvm-dev wrote:> The .dynamic section is almost read-only except for the DT_DEBUG entry > which requires the dynamic linker to modify a word. MIPS has long since had > a solution to this using the DT_MIPS_RLD_MAP entry to give a pointer to > another section which is writable. It would be nice to have this > functionality on other targets as well however.Can we take a step back please? I think a much better approach would be to make the whole DT_DEBUG/DT_MIPS_RLD_MAP optional, not moving from the former hack to the latter hack. Systems that want to support this new mechanism reserve an AUX vector similar to AT_BASE and let the dynamic linker fill it in. No space required in the executable that way. Joerg
Jake Ehrlich via llvm-dev
2017-May-22 19:33 UTC
[llvm-dev] [lld][ELF] Add option to make .dynamic read only
Here's my understanding of Joerg's proposal. 1) Still allow users to emit a read-only .dynamic section 2) Not emit DT_DEBUG in the case of a read-only .dynamic section 3) Do none of this DT_DEBUG_INDIRECT/DT_MIPS_RLD_MAP stuff. We can just allow people to use the AUX vector for this purpose if they need it. So the changes to LLD would include 1) Adding a flag for read-only .dynamic 2) Changing the flags for .dynamic according to this flag 3) Not emitting DT_DEBUG if this flag is set. I think we'd be fine with that option if everyone agrees to it. I already have a patch which does that in fact (it's a very trivial change). Would everyone be ok with this change? On Sat, May 20, 2017 at 4:22 AM Joerg Sonnenberger <joerg at bec.de> wrote:> On Tue, May 16, 2017 at 11:31:13PM +0000, Jake Ehrlich via llvm-dev wrote: > > The .dynamic section is almost read-only except for the DT_DEBUG entry > > which requires the dynamic linker to modify a word. MIPS has long since > had > > a solution to this using the DT_MIPS_RLD_MAP entry to give a pointer to > > another section which is writable. It would be nice to have this > > functionality on other targets as well however. > > Can we take a step back please? I think a much better approach would be > to make the whole DT_DEBUG/DT_MIPS_RLD_MAP optional, not moving from the > former hack to the latter hack. Systems that want to support this new > mechanism reserve an AUX vector similar to AT_BASE and let the dynamic > linker fill it in. No space required in the executable that way. > > Joerg >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170522/2b7b7707/attachment.html>