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