Re: Reducing ld.elf_so relocations and size

[Joerg Sonnenberger <joerg%britannica.bec.de@localhost>]

On Mon, Dec 13, 2010 at 12:52:19AM +0300, Valeriy E. Ushakov wrote:
> Don't drop "DECL" component from __BEGIN_PUBLIC &co.

I don't care, can be changed at any time.

> __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''.

DEFAULT is the visibility setting of "for everyone", yes. Feel free to
provide a better name.

> 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.

K.

> 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.

It is still a libc and it is still using libc code.

> 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.

The "small" part can should be considered for /rescue too. But
essentially yes.

> 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).

The list of things ld.so expects is shorter by the transitive closure
etc. I frankly don't see the point in moving it to ld.so as it just
as complicatcated without any real gain. I would prefer to have all
the libc building stuff in libc and remove the current reach-over from
ld.so -- that has created more trouble than it fixed.

> 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.

The situation to the kernel is quite different. All the libs shared with
the kernel either are trivial fixed lists or handled in config fragments
on the kernel side. If you look at likbern/Makefile.libkern, duplicating
that kind of logic is really not helpful.

Joerg