Re: INT() and INTDEF()

[Jakub Jelinek <jakub at redhat dot com>]

On Sat, Feb 02, 2002 at 04:44:32PM -0800, Ulrich Drepper wrote:
> I just committed a batch of changes which eliminates all unnecessary
> PLT entries from ld.so.  Some functions were exported and also user
> internally.  But these functions must never be interposed.
> 
> The solution is to define aliases and use them instead.  This is what
> the INT and INTDEF macros do.
> 
> It is no big problem to miss adding these wrappers.  The code will run
> just fine.  It's just something which has to be cleaned up before a
> release.  It is a problem to add the macro when it is not needed.
> E.g., the dl-open, dl-close, dl-sym files cannot use them because
> these files end up in libc.so.  The linker will tell you if you've
> done something wrong.
> 
> Besides using INT() I've also removed two symbols from the Versions
> file.  I could find nor think of a place where those are used.  Please
> look out in case you see some problem which could be explained by
> these symbols not being exported.
> 
> The result of the whole exercised that we have 20 PLT entries less,
> saved about 600bytes of text and 60bytes of data, and the linker was
> able to convert PLT calls to cheaper relative calls.  On my machine
> this meant another 5% reduction in startup time.

I think we could use similar thing for _rtld_global (ie. have one .hidden
_rtld_global_internal and _rtld_global for use in libc).
This would require finally applying a patch to recognize
__attribute__((visibility (hidden))) and similar and the compiler could use
this information where appropriate (e.g. on IA-32 it could use @GOTOFF
instead of @GOT for hidden variables).
Instead of:
        movl    _rtld_global@GOT(%ebx), %eax
        movl    8(%eax), %eax
could use:
	movl	8+_rtld_global_internal@GOTOFF(%ebx), %eax
glibc just would have to differentiate at compile time between objects which
will go solely into ld.so and other objects.
Richard, do you think __attribute__((visibility (hidden))) patch might be
acceptable for 3.1 still?

> Using INT in ld.so is only the first step.  If you look at my 2.3 todo
> list you'll see it mentioned for the whole libc.  But the job there
> will be not so easy.  We'll have to decide which symbol can be
> interposed.  There are some obvious candidates (malloc & friends) and
> some necessary one (all function which can cancellable in the thread
> library).  IMO everything else should be private.  If somebody, for
> instance, reliese on fopen() be implemented with a call to open() s/he
> makes an assumption which isn't necessarily true.  open64() could be
> used instead, on micro-kernel systems some lower-level code could be
> used, or (as on the 2.3 list) the syscall could be used directly.  The
> only sane way is to intercept all calls which go into the libc and
> regard the libc itself as a black box.

	Jakub