Re: Reducing ld.elf_so relocations and size

["Valeriy E. Ushakov" <uwe%stderr.spb.ru@localhost>]

On Sat, Dec 11, 2010 at 00:18:05 +0100, Joerg Sonnenberger wrote:

> attached patch in combination with the environment handling patch I send
> earlier addresses two issues with ld.elf_so:
> 
> (1) It has too many runtime relocations because the integrated libc
> doesn't exploit the fact that the non-local references are still hidden.
[...]
> (2) It (almost) allows to drop the special visibility hacks in
> ld.elf_so.
[...]
> I know that the global define trick is not the most beautiful approach,
> but I haven't found an idea that involves less code changes and still
> gives the benefits of (1). More importantly, I would strongly prefer to
> only have to source code as optimisation, not to make it work. I also
> don't want to duplicate the logic from libc to decide where a specific
> source file lives and if the C version or the MD assembler should be
> used. Ideas are welcome.

Don't drop "DECL" component from __BEGIN_PUBLIC &co.

__FORCE_HIDDEN_DEFAULT is a very confusing name, since "default" is
also a kind of visibility, so it's easy to misread it as ``force
"hidden" symbols to have "default" visibility''.

Instead of

        .globl  _C_LABEL(__errno)
+#if defined(__FORCE_HIDDEN_DEFAULT)
+       .hidden _C_LABEL(__errno)
+#endif

or

+#if defined(__FORCE_HIDDEN_DEFAULT)
+#define _ENTRY(x) \
+       .text; _ALIGN_TEXT; .globl x; .hidden x; .type x,@function; x:
+#else
 #define _ENTRY(x) \
        .text; _ALIGN_TEXT; .globl x; .type x,@function; x:
+#endif

Introduce a new define, e.g. PUBLIC_GLOBAL(sym), that expands to
either .global or to .global + .hidden.


I agree with Nick, I don't like the fact that the libc subset is built
in lib/libc.  It's feels like a horrible kludge.

As far as I understand the intended effect (ignoring any optimizations
to the build itself for now) is to link ld.so against something like
the following

   ... libc_pic+hidden_override.a libc_pic+hidden.a

where libc_pic_hidden.a is libc_pic.a but built with
-fvisibility=hidden, and lic_pic_hidden_override.a is also pic+hidden
code that provides alternative, simplified versions of some of the
libc functions.

Potential optimization to the build is that we don't want to actually
build most of the libc code for libc_pic+hidden.a (e.g. we don't
expect ld.so to call NIS).  That knowledge, arguably, "belongs" to
ld.so makefile(s), not to libc makefile(s).

Yes, libc build is somewhat convoluted, with soruces scattered through
the tree.  That doesn't mean that we need to give up and go for a
kludge.  We already have somewhat similar setup for kernel libs, that
provide an include makefile that other makefiles can use to pick up
the logic pertinent to building that code, source files locations etc.
Something similar needs to be done to libc, so ld.so can build it's
own copy privately.

-uwe