This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: building GLIBC with -fsanitize=address
- From: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>
- Date: Wed, 27 Aug 2014 16:08:43 -0700
- Subject: Re: building GLIBC with -fsanitize=address
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdzRLKBsAr5wq_9JMZQ388n84dfW+N9ZDuXfFABdbBbpWw at mail dot gmail dot com> <20140827224548 dot B3FA52C3A1A at topped-with-meat dot com>
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.
>
> 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?).
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).
--kcc
>
>
> Thanks,
> Roland