ld-linux.so.2 and link map

[Mathieu Lacage <mathieu dot lacage at sophia dot inria dot fr>]

hi,

I have spent quite a bit of time to try to figure out the relationship
between symbol resolution with the ELF global scope and the
ld-linux.so.2 symbols mapped in memory. Specifically, I have not found
any information on the position of the ld-linux.so.2 binary in the
global scope. I found a couple of interesting things:

1) libc.so has an explicit dependency on ld-linux.so.2 which naturally
makes any program which depends on libc.so have at least one entry in
their global scope (usually, the last entry) for ld-linux.so.2.
consequently, as expected, if I look at the link map of a binary
dynamically-linked against libc.so, I can always see an ld-linux.so.2
entry somewhere.

2) if I build an executable which does not depend on the system libc.so
and use gdb to look at its link map, I can see that there is no such
ld-linux.so.2 entry in the link map, but, I can also see that,
hopefully, the dynamic loader in still mapped in memory and resolving
symbols since /proc/pid/maps shows it somewhere on top of the stack.

To summarize, it appears that:
  - the dynamic loader is always mapped in memory (which is expected)
  - if I want to insert the dynamic loader in a symbol resolution scope,
I need to link against it explicitely (which, again, is expected)
  - the dynamic loader appears in the process link map only if it is
part of a symbol resolution scope (which surprises me).

Now, to my question: since the link map is unrelated to the symbol
resolution scope of any binary loaded in memory, why does the dynamic
loader appear in it _only_ if I link against it explicitely. Why can't
it appear in the link map unconditionally (which would allow gdb to see
it and debug it even when I don't link against it explicitely and when I
don't use the libc) ?

regards,
Mathieu