naming bounded pointer libraries

[Greg McGary <greg at mcgary dot org>]

[ 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