Re: Reducing ld.elf_so relocations and size

[Nick Hudson <nick.hudson%gmx.co.uk@localhost>]

On Friday 10 December 2010 23:18:05 Joerg Sonnenberger wrote:
> Hi all,
> 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.
> E.g. on AMD64, both data access and function calls can be done relative
> to the instruction pointer without using the GOT. This improves code
> size and startup time. The changes around errlist reduce the number of
> runtime relocations for one for every errno value and give around 3KB on
> AMD64.
> 
> (2) It (almost) allows to drop the special visibility hacks in
> ld.elf_so. Look at the output of 'readelf -s ld.elf_so' and the long
> list of GLOBAL symbols with DEFAULT visiblity. After the patch, only 3
> symbols are still visible that shouldn't be (__bss_start, _edata, _end)
> and they come from the ld script used. It should be fixed to make them
> hidden or protected, but that's a separate discussion.

Wouldn't a simple version script be better here? 

     { global: foo; bar; local: *; };

Doesn't this allow _rtld_is_exported to die?

> The patch is currently missing the !x86 machine/asm.h changes and some
> other minor changes to avoid some GOT references. Some platforms might
> need additional helper code as well, but that's easy to identify.
> 
> The patch also doesn't contain a build time assertion for the symbol
> list of ld.elf_so yet.
> 
> There are some further changes to consider like making __cerror a hidden
> lymbol, taking it out of the public namespace. It would allow taking the
> shorter code sequence for the shared library build as well.
> 

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

To replay my previous comments and add some more

        - Abusing libc/Makefile is awful

        - Extracting make logic into a separate .mk is desirable.

        - AFAICT, most of what you want to achieve can be done with
          {C,CPP,AS}FLAGS - no need for .hpico.

        - Having libc_hidden (or some other name) under libexec/ld.elf_so seems
          sensible

        - the asm stuff is ugly

> Joerg
> 

Nick