This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

INT() and INTDEF()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]