Re: building GLIBC with -fsanitize=address

[Roland McGrath <roland at hack dot frob dot com>]

The machinery based on object-suffixes takes care of having separate object
file builds and archive libraries.  But if you want to make a separate
flavor of shared objects from those, you'll need to duplicate (refactor)
a bunch more rules for doing the actual ld -shared step.

I'm inclined to think that this is not really the right model for an ASan
build.  But to be sure, we need to dig deeper into exactly what you/we
envision an ASan build containing and how it would be used.

The tack you've attempted leads to the single canonical glibc build
(optionally) producing another library variant.  The alternate approach is
a configure switch that changes what the "primary" build does rather than
adding a variant.  That is, you would configure with --enable-asan (or
perhaps this should be --with-asan for this approach) as an orthogonal
switch to --{en,dis}able-{static,shared,profile}.  This build would produce
a libc.so (and libc.a too unless --disable-static) and ld.so built with
-fsanitize=address.  You'd configure this for a different --prefix or
something like that, and the canonical absolute dynamic linker file name
for PT_INTERP would be a different one (perhaps just different because of
the different prefix, or perhaps explicitly modified to be ld...-asan).
Then to build applications with this library, you'd point the compiler
driver's paths at the differently prefixed lib directory and pass the
different name to the linker's -dynamic-linker.

Before getting into more details, I think we need to be clear on the vision
of what you want to produce and how it would be used.


Thanks,
Roland