Re: building GLIBC with -fsanitize=address

[Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>]

So, Roland, what is your final recommendation?
If you still suggest to use a separate build, do you know if there is
anything similar already in the build system (so that I can duplicate
that)?

Thanks,

--kcc

On Wed, Sep 3, 2014 at 6:41 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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.
>