On Tue, Oct 13, 2015 at 4:13 AM, Maxim Ostapenko
<m.ostape...@partner.samsung.com> wrote:
> Hi,
>
> it's been a while since the last libsanitizer merge from upstream into GCC
> happened and the library has significantly changed since that time. The main
> features to be ported are:
>
> -New common strings interceptors were added.
> -Various allocator improvements were performed.
> -Improvements for ASan deactivated start were performed.
> -TSan and LSan were enabled for Aarch64.
> -Fast unwinding was enabled for Aarch64.
> -New tsan_unaligned_{load, store}_[n] functions were intoduced.
> -asan_stack_malloc_[n] doesn't take a local stack as a second parameter
> anymore.
> -sanitization for std containers is supported now.
> -New interface functions for dynamic allocas and VLA's poisoning/unpoisoning
> were introduced.
>
> Some features are not ported for now, by might be enabled in future:
>
> -Embedded UBSan runtime into ASan and TSan ones. I don't enable this now,
> because of errors during ASan static linkage: GCC uses -whole-archive option
> that would lead to undefined references to C++ stuff.
> -UBSan data descriptors for float-cast conversion support location
> propagation now. But sometimes we have loc == UNKNOWN_LOCATION in
> ubsan_instrument_float_cast, so use old ABI for now. See below for details.
>
> The first patch of the series is the merge itself.
>
> The second one introduces corresponding compiler changes.
>
> Other patches are applied to library and they are GCC-specific:
>
> Patches 3 and 4 are just reapplied David's and Jakub's patches for SPARC and
> disabling ODR violation detection respectively.
>
> Patch 5 removes UBSan stubs from ASan and TSan code since we don't support
> embedded UBSan runtime into ASan and TSan.
>
> Patch 6 changes heuristic for extracting last PC from stack frame for ARM in
> fast unwind routine. More details can be found here
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61771).
>
> Patch 7 forces libsanitizer to use an old ABI for ubsan float cast data
> descriptors, because sometimes we can have loc == UNKNOWN_LOCATION in
> ubsan_instrument_float_cast e.g. in a such case:
>
> ......
> volatile double foo; // ubsan_instrument_float_cast is called by convert
> function.
> ......
>
> Since foo is a tcc_declaration, loc is UNKNOWN_LOCATION. I'm actually not
> sure about this, perhaps we can fix this in GCC somehow.
>
> I've regtested and {A, UB}San bootstrapped these patches on
> x86-64-unknown-linux-gnu and aarch64-linux-gnueabi (Juno board, 39 bit VA
> space) and tested for ARM under QEMU-ARM.
> Testing ASan under QEMU-AARCH64 revealed many test failures due to LSan was
> enabled. In particular, it tries to call internal_clone function in LSan
> internals, that in turn calls _NR_clone syscall and than QEMU exits with
> EINTR error code (that might be expected, AFAIK QEMU is not very good with
> threads). So, I wonder, if I should disable LSan for AArch64 now?We should just disable ASAN and TSAN for AARCH64 until 48bit VA is supported. Since the majority of the distros are going to be using 48bit VA as it is required to be used to support dual node ThunderX (since ThunderX's physical address space uses all 48bits). Thanks, Andrew Pinski > > I'm also asking community to help me with testing these patches on various > targets (ARM, PPC, etc) I'm lack of, so could you help me on this please? > > -Maxim
