This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: libsanitizer merge from upstream r221802
- From: Dmitry Vyukov <dvyukov at google dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Dodji Seketeli <dodji at redhat dot com>, Marek Polacek <polacek at redhat dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, Yuri Gribov <tetra2005 at gmail dot com>, Alexey Samsonov <samsonov at google dot com>
- Date: Fri, 21 Nov 2014 16:20:44 +0400
- Subject: Re: libsanitizer merge from upstream r221802
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdybHEXUYZ3xCaadBAi5U7mTmGkHK8yweF6Qts5q=yc42Q at mail dot gmail dot com> <20141113091614 dot GB5026 at tucnak dot redhat dot com>
On Thu, Nov 13, 2014 at 12:16 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> 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 <kcc@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.
Hi Jakub,
Yes, I think it's the way to go.
I've just committed the following revision to clang that removes -pie
when compiling with tsan:
http://llvm.org/viewvc/llvm-project?view=revision&revision=222526
The tests in llvm tree pass with this change.