I am implementing bounds checking in gcc and glibc.
glibc changes are almost all checked into CVS.
Next week, I'll start checking in gcc mods.
First some background:
My approach uses "bounded pointers". A bounded pointer is a 3-word
object that carries the normal pointer value along with a low and high
bound. With `gcc ... -fbounded-pointers', gcc generates code to
manage the bounded pointers and to check that the pointer values lies
between the bounds prior to dereference.
You can see that code compiled with `-fbounded-pointers' does not mix
well with code compiled without, since the size of a fundamental data
type changes. In order to prevent accidentally mixing BP and non-BP
functions, gcc prepends "__BP_" to the name of every function that has
a pointer in its arg-type/return-type signature.
Now, the problem autoconf:
The AC_CHECK_FUNCS macro detects the presence of a function by
attempting to link a tiny test program that uses the function. If the
link is successful, then the function is known to exist in the
library. The problem for BPs is that the test program uses a fake and
simplistic declaration of the function with return type char and no
arg types. Thus, `gcc -fbounded-pointers' will compile it without
the" __BP_" prefix, but if the function really has pointers in its
signature, it will exist in a BP-compiled library with the prefix and
we'll improperly get a link failure.
Why would someone want to `-fbounded-pointers' at configure time?
It's preferable to configure with what one will actually build with.
It's possible to configure with the non-BP glibc, then substitute the
BP glibc at build time. However, if I do a cvs update that changes
some config files, the next time I type `make' to build with BPs,
config.status will run with BPs in force. To get past this, I must
remember to explicitly re-run configure (without BPs) to update the
configuration before running the build with BPs. Anyway, it's a pain
and will hinder the use of BPs for normal development work.
It seems to me that the simple solution is teach AC_CHECK_FUNCS (and
others?) which library functions have pointers in their signatures,
and then conditionally declare as `char foo ()' or `char *foo ()' in
the test program. Sound reasonable? Any ideas on how to implement
this with the least impact on configure.in files?
One idea is that we could maintain a text database of library
function names and indication of whether they have pointers in
their sigs. This could be consulted at autoconf time or at configure
time (whichever is more convenient) to determine which decl to use.
This seems like significant work though, and only works as well as
the database is complete and accurate.
Another idea is to detect the presence of `-fbounded-pointers' in
the configuration-time CFLAGS and if present, do a second run
of each AC_CHECK_FUNCS test that fails. The first test will use
the traditional decl, and the backup test will use `char *foo ()'
to see if perhaps the first test failed because foo is defined
with the "__BP_" prefix.
I this second idea since it seems like much less work, and the only
penalty is CPU at configuration time and only for users of
`-fbounded-pointers'.
Comments?
Greg
