[PATCH] D33251: [lld][ELF]Add option to make .dynamic read only

[Roland McGrath via llvm-commits]

On Wed, May 24, 2017 at 9:21 AM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
> Roland McGrath <mcgrathr at google.com> writes:
>
>> Rafael mentioned "something with aux vectors", but I don't know what he
>> had in mind.  The ElfNN_auxv_t kind of auxiliary vector in many Unix-like
>> systems' ELF ABIs is a one-way channel of information at program loading
>> time, not a way that the dynamic linker can record something to be seen
>> later.  (For example, on Linux, /proc/$pid/auxv and NT_AUXV notes in core
>> files are a snapshot of the bits given the program on startup, not a dump
>> gleaned from the program's memory where it could have modified them.)
>
> The suggestion is from Joerg actually:
>
> ---------------------------------------------------------
> 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.
> ---------------------------------------------------------
>
> It sound similar, no? Both are a way of passing a pointer to the
> process. Once the process has a pointer to what now is pointed by
> DT_DEBUG it can walk it as it does now.

I'm still not completely clear on what this suggestion is.
As I said above, modifying an auxv entry itself does not fill the need.
There's only one plan based on auxv I can think of that would work,
so perhaps that is what Joerg actually meant:

The kernel provides a new entry {AT_FOO, <addr>} where <addr> is the
address of some word
(presumably on the initial stack the kernel sets up, near where auxv
itself is passed at startup).
Then the dynamic linker can store &r_debug at *<addr>.
Debuggers can find AT_FOO in /proc/$pid/auxv or NT_AUXV to discover <addr>.