This is the mail archive of the libc-alpha@sourceware.org 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


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


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