[RFC PATCH] Merge libsanitizer from upstream

Christophe Lyon christophe.lyon@linaro.org
Fri Oct 20 10:48:00 GMT 2017


Hi,

On 19 October 2017 at 13:17, Jakub Jelinek <jakub@redhat.com> wrote:
> On Thu, Oct 19, 2017 at 02:07:24PM +0300, Maxim Ostapenko wrote:
>> > Is the patch (the merge + this incremental) ok for trunk?
>>
>> I think the patch is OK, just wondering about two things:
>
> Richi just approved the patch on IRC, so I'll commit, then we can deal with
> follow-ups.
>

Does anyone else run these tests on arm?
Since you applied this patch, I'm seeing lots of new errors and timeouts.
I have been ignoring regression reports for *san because of yyrandomness
in the results, but the timeouts are a  major inconvenience in testing
because it increases latency a lot in getting results, or worse I get no
result at all because the validation job is killed before completion.

Looking at some intermediate logs, I have noticed:
==24797==AddressSanitizer CHECK failed:
/libsanitizer/asan/asan_poisoning.cc:34
"((AddrIsAlignedByGranularity(addr))) != (0)" (0x0, 0x0)
    #0 0x408d7d65 in AsanCheckFailed /libsanitizer/asan/asan_rtl.cc:67
    #1 0x408ecd5d in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
/libsanitizer/sanitizer_common/sanitizer_termination.cc:77
    #2 0x408d22d5 in __asan::PoisonShadow(unsigned long, unsigned
long, unsigned char) /libsanitizer/asan/asan_poisoning.cc:34
    #3 0x4085409b in __asan_register_globals
/libsanitizer/asan/asan_globals.cc:368
    #4 0x109eb in _GLOBAL__sub_I_00099_1_ten
(/aci-gcc-fsf/builds/gcc-fsf-gccsrc-thumb/obj-arm-none-linux-gnueabi/gcc3/gcc/testsuite/gcc/alloca_big_alignment.exe+0x109eb)

in MANY (193 in gcc) tests.

and many others (152 in gcc) just time out individually (eg
c-c++-common/asan/alloca_instruments_all_paddings.c) with no error in
the logs besides Dejagnu's
WARNING: program timed out.


Since I'm using an apparently unusual setup, maybe I have to update it
to cope with the new version,
so I'd like to know if others are seeing the same problems on arm?

I'm using qemu -R 0 to execute the test programs, encapsulated by
proot (similar to chroot, but does not require root privileges).

Am I missing something obvious?

Thanks,

Christophe


>> 1) We have a bunch of GCC local patches, did you include them into a
>> cumulative patch (I guess yes)?
>
> I have done some verification today, diff from upstream r285547 to unpatched
> GCC (with the LLVM Compiler infrastructure two liners removed), attached P1,
> and diff from upstream r315899 to patched GCC (again, two liners removed),
> attached P2 and went through the changes in P1 and verified that except for
> the ubsan backwards compatibility we had that can't work anymore everything
> else was upstreamed, or remained in P2.  So P2 is the current diff from
> upstream, with the sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
> changes now filed upstream.
>
>> 2) Upstream has enabled LSan for x86 and ARM, is it worth to enable them in
>> GCC too?
>
> Maybe, feel free to post patches.  For LSan we need to split off lsan_preinit
> out of liblsan and link it into executables, will handle it next (there is a
> PR about it, just wanted to wait until the merge is in).
>
>         Jakub



More information about the Gcc-patches mailing list