[llvm-dev] [lld][ELF] Add option to make .dynamic read only

Jake Ehrlich via llvm-dev llvm-dev at lists.llvm.org
Mon May 22 12:33:31 PDT 2017


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>


More information about the llvm-dev mailing list