INT() and INTDEF()

INT() and INTDEF()

[Ulrich Drepper]

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.


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.

-- 
---------------.                          ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Red Hat          `--' drepper at redhat.com   `------------------------

Re: INT() and INTDEF()

[Jakub Jelinek]

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