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] |
[ For background, I recommend the bounded pointers project page at http://gcc.gnu.org/projects/bp/main.html ] My original scheme for libc was to suffix `_b', making `libc_b.a', analogous to what was already done for the profiling libc as `libc_p.a'. I needed to fiddle with the gcc specs to link with `-lc_b' and to use startup file `bcrt1.o'. That all works fine for programs that use only libc. Now that I am testing more widely, I encounter programs that want BP versions of other libraries, notably libm. If the library in question is part of glibc, it's already installed as `lib*_b.a', so for math, it's simply a matter of altering the ld command-line to use `-lm_b'. I fear this is going to get very messy. Something must take responsibility for qualifying BP libs with the `_b' suffix. It could be done a number of ways: 1) Have gcc do it. Bad idea. Gcc is not designed to conveniently massage `-l' switches like that. 2) Have ld do it. This is a possibility. Give ld a new option which says use the suffixed library name if present. The suffix could be passed to ld, so that it could work for other suffixes besides `_b', say for use with profiled libs beyond libc_p.a. OTOH, this is not so great since ld already has a zillion options. 3) Drop the suffix and instead install special libraries in a subdir, e.g. /usr/lib/libc.a (regular), /usr/lib/bp/libc.a (bounded), /usr/lib/prof/libc.a (profiled), and so on for any lib. Now, something still must be responsible for directing ld to prefer the appropriate subdir. ... 3a) Gcc could do it in the specs by passing `-L' options which give precedence to the specialized subdirs, also in this case gcc would need to assume knowledge of where all the default library dirs reside and could no longer assume ld knew where to find everything. Any makefile that invokes ld directly would need to do that job for itself. ... 3b) we could go back to (2) above and introduce an option to ld that provides a specialized-library-subdir name which ld could append to all dirnames in its library path. Gcc specs could easily propagate `-p*' and `-fbounded-pointers' to ld as the appropriate subdir option. This is substantially the same as (2)--only the string substitution rule on library dir names differs. None of these automatic approaches is conducive to individually selecting BP vs. non-BP libraries if both versions exist (e.g., my system has both BP and non-BP X11 libraries, I'm compiling with BPs in my application code, but for performance's sake, I want non-BP X11 libs). On the BP project page I classify intentional mixing of BP and non-BP code as only a `maybe goal', mostly because in the general case it seems too damn hard to do. I still cling to the hope that with appropriate optimizations, runtime & space overhead for BP programs will be less than 50% (i.e., <1.5x slowdown & <1.5x bloat), so the need to selectively mix code will not be so urgent. Note that there is a fallback safety mechanism for the BP case: if the wrong library is chosen, there will be undefined symbols since BP functions have their names mangled. (BP-mangled vs. non-mangled for C, and BP-mangled vs. traditionally-mangled for C++). At this point, I lean toward (2) or (3b). Any better ideas? Greg
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |