On Wed, Nov 12, 2014 at 05:35:48PM -0800, Konstantin Serebryany wrote:
> Here is one more merge of libsanitizer (last one was in Sept).
>
> Tested on x86_64 Ubuntu 14.04 like this:
> rm -rf */{*/,}libsanitizer && make -j 50
> make -j 40 -C gcc check-g{cc,++}
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp' && \
> make -j 40 -C gcc check-g{cc,++}
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} tsan.exp' && \
> make -j 40 -C gcc check
> RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} ubsan.exp' && \
> echo PASS
>
> Expected ChangeLog entry:
>
> 2014-11-12 Kostya Serebryany <k...@google.com>
>
> * All source files: Merge from upstream r221802.
> * sanitizer_common/sanitizer_symbolizer_libbacktrace.cc
> (LibbacktraceSymbolizer::SymbolizeData): replace 'address'
> with 'start' to follow the new interface.
Capital R in Replace. All lines are indented by single tab, not tab
and two spaces.
> * asan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
Capital A in Added. Also, I wonder if we shouldn't use -std=gnu++11
instead. As the sources are compiled by newly built compiler, it should be
generally fine to use extensions in there.
> * interception/Makefile.am (AM_CXXFLAGS): added -std=c++11.
> * libbacktrace/Makefile.am (AM_CXXFLAGS): added -std=c++11.
> * lsan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
> * sanitizer_common/Makefile.am (sanitizer_common_files): Added new
> files.
> (AM_CXXFLAGS): added -std=c++11.
> * tsan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
> * ubsan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
Ditto.
> * asan/Makefile.in: Regenerate.
> * interception/Makefile.in: Regenerate.
> * libbacktrace/Makefile.in: Regenerate.
> * lsan/Makefile.in: Regenerate.
> * sanitizer_common/Makefile.in: Regenerate.
> * tsan/Makefile.in: Regenerate.
> * ubsan/Makefile.in: Regenerate.
Other than that, it looks good to me, I've bootstrapped/regtested
it on x86_64-linux and i686-linux too. So, with those changes ok for trunk
(how do you decide about c++11 vs. gnu++11 I'll leave to you).
A few questions regarding possible changes on the compiler side:
1) is __asan_poison_intra_object_redzone/__asan_unpoison_intra_object_redzone
just for the ABI incompatible putting of red zones in between fields
in structures? How do you handle whole struct copying in that case?
Could it be done without changing ABI for a subset of structs
which have natural padding in them?
2) regarding the tsan memory layout changes, is it now possible to support
non-pie binaries? If yes, we should probably remove the:
%{!pie:%{!shared:%e-fsanitize=thread linking must be done with -pie or
-shared}}}\
and add testcases that would test that.
Jakub
