This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: building GLIBC with -fsanitize=address

here is the compiler wrapper script that tampers with the compiler
flags to build
ASan-instrumented glibc w/o changing the glibc sources:

With this I can build the full glibc (tested on 2.19 and 2.20) with
asan instrumentation and find injected bugs.
Now I can move further; however it would still be great if someone can
assist me with properly patching the glibc build system to support
asan build.


On Mon, Sep 15, 2014 at 3:11 PM, Konstantin Serebryany
<> wrote:
> 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 <> wrote:
>> On 08/27/2014 07:08 PM, Konstantin Serebryany wrote:
>>> On Wed, Aug 27, 2014 at 3:45 PM, Roland McGrath <> 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 (and libc.a too unless --disable-static) and 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
>> 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 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 (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, maybe a few more).
>> We can, but then it becomes a set of more custom rules for
>> building
>> 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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]