Re: building GLIBC with -fsanitize=address

["Carlos O'Donell" <carlos at redhat dot com>]

On 08/27/2014 07:08 PM, Konstantin Serebryany wrote:
> On Wed, Aug 27, 2014 at 3:45 PM, Roland McGrath <roland@hack.frob.com> wrote:
>> 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.

Configuring with an alternate --prefix defeats one of the main reasons
I want this. I would like to run an entire Fedora bootstrap, or part of
one, with ASan turned on in glibc. Therefore it has to look like dropin
libc.so.6. Nothing in your plan prevents me from doing that, but I just
wanted to point out that alternate --prefix and building everything with
-Wl,--dynamic-linker= goes against my use case. Even though I'm
bootstraping it's always a problem to get flags down into all of the
right places to make the system use a non-default loader (without wrapping
gcc itself).

>> 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.
> 
> As long as I can link the resulting instrumented libc.so to binaries
> and run them
> either way works for me. The idea with reusing the -pg approach (which
> I think came from Carlos?),
> is nice because -pg has similar properties, i.e. we can not add -pg to
> objects going to ld.so (right?).

Correct, which is why I recommended the -pg approach.

> A primary build option (--with-asan) is fine too as long as we can
> omit -fsanitize=address when building
> some objects (e.g. those for ld.so, maybe a few more).

We can, but then it becomes a set of more custom rules for
building ld.so.

I'm still inclined to think the -pg route is the least work
for ASan, but Roland actually has the best experience to
comment on the amount of work he thinks is required from
each solution.

Cheers,
Carlos.