I am not sure I understand the problem,
but whatever the problem is I am against using -std=gnu++ as this will
be a different flag combination from what we have upstream.
On Fri, Nov 14, 2014 at 8:50 AM, Konstantin Serebryany
<konstantin.s.serebry...@gmail.com> wrote:
> Let's continue the discussion there, we can do another merge quickly
> or do a cherry pick to GCC once we have a solution.
> So far I don't see one. (other than not supporting the old kernels, of course)
>
> On Fri, Nov 14, 2014 at 2:38 AM, Christophe Lyon
> <christophe.l...@linaro.org> wrote:
>> On 13 November 2014 21:44, Konstantin Serebryany
>> <konstantin.s.serebry...@gmail.com> wrote:
>>> On Thu, Nov 13, 2014 at 1:16 AM, Jakub Jelinek <ja...@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 <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.
>>>
>>> in llvm we use -std=c++11, so I use it here for consistency.
>>>
>>>>
>>>>> * 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).
>>>
>>> Fixed all, committed. r217518.
>>>
>>
>> Hmm
>> So as already reported on the llvm lists, this has the side effect of
>> breaking the build for aarch64 when using "old" kernel headers.
>> I wish the discussion at
>> http://reviews.llvm.org/D6026
>> had converged before merging incorrect things into GCC.
>>
>>>
>>>>
>>>> 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?
>>>
>>> This is all highly experimental:
>>> https://code.google.com/p/address-sanitizer/wiki/IntraObjectOverflow
>>> Currently we apply this instrumentation only to C++ classes that are
>>> a) non-standard-layout, i.e. we are allowed by the standard to
>>> reshuffle the fields and add paddings.
>>> b) have a DTOR, where we can do the unpoison.
>>> Even with this strict limitation we hit lots of failures where users
>>> make assumptions about the layout or size of non-standard-layout
>>> types.
>>> We do find juicy bugs in this mode so we'll likely continue the
>>> investigation and try to reduce the current limitations.
>>>
>>>> Could it be done without changing ABI for a subset of structs
>>>> which have natural padding in them?
>>> Quite likely. But we will need to figure out where to unpoison the paddings.
>>>
>>>> 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.
>>>
>>> Yes, that was one of the reasons for the change.
>>> But let's hear from Dmitry if he is ready to remove -pie now or wants
>>> to do some more testing.
>>>
>>> --kcc
>>>
>>>>
>>>> Jakub
