Re: building GLIBC with -fsanitize=address

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

On Thu, Sep 25, 2014 at 10:57 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/23/2014 08:41 PM, Konstantin Serebryany wrote:
>> FTR:
>> here is the compiler wrapper script that tampers with the compiler
>> flags to build
>> ASan-instrumented glibc w/o changing the glibc sources:
>> https://code.google.com/p/address-sanitizer/source/browse/trunk/asan-glibc/asan-glibc-gcc-wrapper.py
>>
>> 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.
>
> Have you been able to make progress on logging instead of faulting on
> error?
>
> We can help with glibc builds, but it would be nice to make sure that
> if we were to turn it on that it won't cause the system to immediately
> abort at boot time when it detects errors.
>
> Recall our conversation at Cauldron 2014, in that ASan + glibc needs to
> log errors as precisely as possible for later offline analysis by the
> distribution team maintaining glibc.
>
> Does that goal still make sense?

Yes, the goal still makes sense.
Today, both GCC and Clang asan implementations have flags to emit
instrumentation via callbacks instead of inline code.
It makes asan somewhat slower, but allows to continue after the first report.

% cat load.c
int load(int *a) { return *a; }
% ~/gcc-inst/bin/gcc -fsanitize=address -O -S -o -   --param
asan-instrumentation-with-call-threshold=0 load.c
pushq %rbx
movq %rdi, %rbx
call __asan_load4
movl (%rbx), %eax
popq %rbx
ret

We may need very minor additional changes in asan-run-time, but we
will need them anyway to support whatever kind of logging you need for
glibc.

--kcc

>
> Cheers,
> Carlos.
>