* Re: libsanitizer merge from upstream r221802
@ 2014-11-14 11:41 Uros Bizjak
2014-11-14 14:35 ` Uros Bizjak
0 siblings, 1 reply; 20+ messages in thread
From: Uros Bizjak @ 2014-11-14 11:41 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek, Konstantin Serebryany
Hello!
> 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.
> * asan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
> * 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.
> * 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.
This patch breaks CENTOS5 build with:
In file included from /usr/include/asm-x86_64/byteorder.h:30:0,
from /usr/include/asm/byteorder.h:5,
from /usr/include/linux/aio_abi.h:30,
from
/home/uros/gcc-svn/trunk/libsanitizer/include/system/linux/aio_abi.h:2,
from
../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:49:
/usr/include/linux/byteorder/little_endian.h:43:19: error: ‘__le64’
does not name a type
static __inline__ __le64 __cpu_to_le64p(const __u64 *p)
^
/usr/include/linux/byteorder/little_endian.h:47:46: error: ‘__le64’
does not name a type
static __inline__ __u64 __le64_to_cpup(const __le64 *p)
^
/usr/include/linux/byteorder/little_endian.h:67:19: error: ‘__be64’
does not name a type
static __inline__ __be64 __cpu_to_be64p(const __u64 *p)
^
/usr/include/linux/byteorder/little_endian.h:71:46: error: ‘__be64’
does not name a type
static __inline__ __u64 __be64_to_cpup(const __be64 *p)
^
gmake[4]: *** [sanitizer_platform_limits_linux.lo] Error 1
gmake[4]: Leaving directory
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libsanitizer/sanitizer_common'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libsanitizer'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/home/uros/gcc-build/x86_64-unknown-linux-gnu/libsanitizer'
gmake[1]: *** [all-target-libsanitizer] Error 2
Uros.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-14 11:41 libsanitizer merge from upstream r221802 Uros Bizjak
@ 2014-11-14 14:35 ` Uros Bizjak
2014-11-14 14:48 ` Jakub Jelinek
0 siblings, 1 reply; 20+ messages in thread
From: Uros Bizjak @ 2014-11-14 14:35 UTC (permalink / raw)
To: gcc-patches; +Cc: Jakub Jelinek, Konstantin Serebryany
[-- Attachment #1: Type: text/plain, Size: 4850 bytes --]
On Fri, Nov 14, 2014 at 12:31 PM, Uros Bizjak <ubizjak@gmail.com> 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.
>> * asan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
>> * 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.
>> * 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.
>
> This patch breaks CENTOS5 build with:
>
> In file included from /usr/include/asm-x86_64/byteorder.h:30:0,
> from /usr/include/asm/byteorder.h:5,
> from /usr/include/linux/aio_abi.h:30,
> from
> /home/uros/gcc-svn/trunk/libsanitizer/include/system/linux/aio_abi.h:2,
> from
> ../../../../gcc-svn/trunk/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:49:
> /usr/include/linux/byteorder/little_endian.h:43:19: error: ‘__le64’
> does not name a type
> static __inline__ __le64 __cpu_to_le64p(const __u64 *p)
> ^
> /usr/include/linux/byteorder/little_endian.h:47:46: error: ‘__le64’
> does not name a type
> static __inline__ __u64 __le64_to_cpup(const __le64 *p)
> ^
> /usr/include/linux/byteorder/little_endian.h:67:19: error: ‘__be64’
> does not name a type
> static __inline__ __be64 __cpu_to_be64p(const __u64 *p)
> ^
> /usr/include/linux/byteorder/little_endian.h:71:46: error: ‘__be64’
> does not name a type
> static __inline__ __u64 __be64_to_cpup(const __be64 *p)
> ^
> gmake[4]: *** [sanitizer_platform_limits_linux.lo] Error 1
> gmake[4]: Leaving directory
> `/home/uros/gcc-build/x86_64-unknown-linux-gnu/libsanitizer/sanitizer_common'
> gmake[3]: *** [all-recursive] Error 1
> gmake[3]: Leaving directory
> `/home/uros/gcc-build/x86_64-unknown-linux-gnu/libsanitizer'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory
> `/home/uros/gcc-build/x86_64-unknown-linux-gnu/libsanitizer'
> gmake[1]: *** [all-target-libsanitizer] Error 2
The missing definition in system's /usr/include/linux/types.h is protected with:
typedef __u16 __bitwise __le16;
typedef __u16 __bitwise __be16;
typedef __u32 __bitwise __le32;
typedef __u32 __bitwise __be32;
#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
typedef __u64 __bitwise __le64;
typedef __u64 __bitwise __be64;
#endif
which doesn't work with -std=c++11, but works without problems with
-std=gnu++11.
As proposed by Jakub at [1], -std=gnu++11 fixes the problem with old
kernels. Attached patch implements this proposal.
2014-11-14 Uros Bizjak <ubizjak@gmail.com>
* sanitizer_common/Makefile.am (AM_CXXFLAGS): Use -std=gnu++11.
* asan/Makefile.am (AM_CXXFLAGS): Ditto.
* lsan/Makefile.am (AM_CXXFLAGS): Ditto.
* interception/Makefile.am (AM_CXXFLAGS): Ditto.
* tsan/Makefile.am (AM_CXXFLAGS): Ditto.
* libbacktrace/Makefile.am (AM_CXXFLAGS): Ditto.
* ubsan/Makefile.am (AM_CXXFLAGS): Ditto.
* sanitizer_common/Makefile.in: Regenerate.
* asan/Makefile.in: Ditto.
* lsan/Makefile.in: Ditto.
* interception/Makefile.in: Ditto.
* tsan/Makefile.in: Ditto.
* libbacktrace/Makefile.in: Ditto.
* ubsan/Makefile.in: Ditto.
Bootstrapped and regtested on CENTOS 5 x86_64-linux-gnu.
[1] https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01420.html
Uros.
[-- Attachment #2: s.diff.txt --]
[-- Type: text/plain, Size: 8375 bytes --]
Index: sanitizer_common/Makefile.in
===================================================================
--- sanitizer_common/Makefile.in (revision 217538)
+++ sanitizer_common/Makefile.in (working copy)
@@ -253,8 +253,8 @@
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
-fomit-frame-pointer -funwind-tables -fvisibility=hidden \
- -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) -std=c++11 \
- $(am__append_1)
+ -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) \
+ -std=gnu++11 $(am__append_1)
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = libsanitizer_common.la
sanitizer_common_files = \
Index: sanitizer_common/Makefile.am
===================================================================
--- sanitizer_common/Makefile.am (revision 217538)
+++ sanitizer_common/Makefile.am (working copy)
@@ -6,7 +6,7 @@
DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
if LIBBACKTRACE_SUPPORTED
AM_CXXFLAGS += -DSANITIZER_LIBBACKTRACE -DSANITIZER_CP_DEMANGLE \
-I $(top_srcdir)/../libbacktrace \
Index: asan/Makefile.am
===================================================================
--- asan/Makefile.am (revision 217538)
+++ asan/Makefile.am (working copy)
@@ -9,7 +9,7 @@
endif
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf
AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
ACLOCAL_AMFLAGS = -I $(top_srcdir) -I $(top_srcdir)/config
toolexeclib_LTLIBRARIES = libasan.la
Index: lsan/Makefile.in
===================================================================
--- lsan/Makefile.in (revision 217538)
+++ lsan/Makefile.in (working copy)
@@ -260,7 +260,8 @@
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
-fomit-frame-pointer -funwind-tables -fvisibility=hidden \
- -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) -std=c++11
+ -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) \
+ -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = libsanitizer_lsan.la
@LSAN_SUPPORTED_TRUE@toolexeclib_LTLIBRARIES = liblsan.la
Index: lsan/Makefile.am
===================================================================
--- lsan/Makefile.am (revision 217538)
+++ lsan/Makefile.am (working copy)
@@ -6,7 +6,7 @@
DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = libsanitizer_lsan.la
Index: interception/Makefile.in
===================================================================
--- interception/Makefile.in (revision 217538)
+++ interception/Makefile.in (working copy)
@@ -225,7 +225,8 @@
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
-fomit-frame-pointer -funwind-tables -fvisibility=hidden \
- -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) -std=c++11
+ -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) \
+ -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = libinterception.la
interception_files = \
Index: interception/Makefile.am
===================================================================
--- interception/Makefile.am (revision 217538)
+++ interception/Makefile.am (working copy)
@@ -6,7 +6,7 @@
DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
noinst_LTLIBRARIES = libinterception.la
Index: tsan/Makefile.in
===================================================================
--- tsan/Makefile.in (revision 217538)
+++ tsan/Makefile.in (working copy)
@@ -276,7 +276,8 @@
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
-fomit-frame-pointer -funwind-tables -fvisibility=hidden \
- -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) -std=c++11
+ -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) \
+ -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
toolexeclib_LTLIBRARIES = libtsan.la
tsan_files = \
Index: tsan/Makefile.am
===================================================================
--- tsan/Makefile.am (revision 217538)
+++ tsan/Makefile.am (working copy)
@@ -6,7 +6,7 @@
DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
toolexeclib_LTLIBRARIES = libtsan.la
Index: libbacktrace/Makefile.in
===================================================================
--- libbacktrace/Makefile.in (revision 217538)
+++ libbacktrace/Makefile.in (working copy)
@@ -270,7 +270,7 @@
C_WARN_FLAGS = $(WARN_FLAGS) -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
CXX_WARN_FLAGS = $(WARN_FLAGS) -Wno-unused-parameter
AM_CFLAGS = $(C_WARN_FLAGS)
-AM_CXXFLAGS = $(CXX_WARN_FLAGS) -fno-rtti -fno-exceptions -std=c++11
+AM_CXXFLAGS = $(CXX_WARN_FLAGS) -fno-rtti -fno-exceptions -std=gnu++11
noinst_LTLIBRARIES = libsanitizer_libbacktrace.la
libsanitizer_libbacktrace_la_SOURCES = \
../../libbacktrace/backtrace.h \
Index: libbacktrace/Makefile.am
===================================================================
--- libbacktrace/Makefile.am (revision 217538)
+++ libbacktrace/Makefile.am (working copy)
@@ -40,7 +40,7 @@
CXX_WARN_FLAGS = $(WARN_FLAGS) -Wno-unused-parameter
AM_CFLAGS = $(C_WARN_FLAGS)
AM_CXXFLAGS = $(CXX_WARN_FLAGS) -fno-rtti -fno-exceptions
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
noinst_LTLIBRARIES = libsanitizer_libbacktrace.la
Index: ubsan/Makefile.in
===================================================================
--- ubsan/Makefile.in (revision 217538)
+++ ubsan/Makefile.in (working copy)
@@ -256,7 +256,8 @@
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic \
-Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti \
-fomit-frame-pointer -funwind-tables -fvisibility=hidden \
- -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) -std=c++11
+ -Wno-variadic-macros $(LIBSTDCXX_RAW_CXX_CXXFLAGS) \
+ -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
toolexeclib_LTLIBRARIES = libubsan.la
ubsan_files = \
Index: ubsan/Makefile.am
===================================================================
--- ubsan/Makefile.am (revision 217538)
+++ ubsan/Makefile.am (working copy)
@@ -6,7 +6,7 @@
DEFS = -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DPIC
AM_CXXFLAGS = -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros
AM_CXXFLAGS += $(LIBSTDCXX_RAW_CXX_CXXFLAGS)
-AM_CXXFLAGS += -std=c++11
+AM_CXXFLAGS += -std=gnu++11
ACLOCAL_AMFLAGS = -I m4
toolexeclib_LTLIBRARIES = libubsan.la
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-14 14:35 ` Uros Bizjak
@ 2014-11-14 14:48 ` Jakub Jelinek
0 siblings, 0 replies; 20+ messages in thread
From: Jakub Jelinek @ 2014-11-14 14:48 UTC (permalink / raw)
To: Uros Bizjak; +Cc: gcc-patches, Konstantin Serebryany
On Fri, Nov 14, 2014 at 03:11:16PM +0100, Uros Bizjak wrote:
> The missing definition in system's /usr/include/linux/types.h is protected with:
>
> typedef __u16 __bitwise __le16;
> typedef __u16 __bitwise __be16;
> typedef __u32 __bitwise __le32;
> typedef __u32 __bitwise __be32;
> #if defined(__GNUC__) && !defined(__STRICT_ANSI__)
> typedef __u64 __bitwise __le64;
> typedef __u64 __bitwise __be64;
> #endif
>
> which doesn't work with -std=c++11, but works without problems with
> -std=gnu++11.
>
> As proposed by Jakub at [1], -std=gnu++11 fixes the problem with old
> kernels. Attached patch implements this proposal.
>
> 2014-11-14 Uros Bizjak <ubizjak@gmail.com>
>
> * sanitizer_common/Makefile.am (AM_CXXFLAGS): Use -std=gnu++11.
> * asan/Makefile.am (AM_CXXFLAGS): Ditto.
> * lsan/Makefile.am (AM_CXXFLAGS): Ditto.
> * interception/Makefile.am (AM_CXXFLAGS): Ditto.
> * tsan/Makefile.am (AM_CXXFLAGS): Ditto.
> * libbacktrace/Makefile.am (AM_CXXFLAGS): Ditto.
> * ubsan/Makefile.am (AM_CXXFLAGS): Ditto.
> * sanitizer_common/Makefile.in: Regenerate.
> * asan/Makefile.in: Ditto.
> * lsan/Makefile.in: Ditto.
> * interception/Makefile.in: Ditto.
> * tsan/Makefile.in: Ditto.
> * libbacktrace/Makefile.in: Ditto.
> * ubsan/Makefile.in: Ditto.
Ok, thanks. Really no reason for pedantic checking.
Jakub
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-12-31 12:36 ` David Abdurachmanov
@ 2015-01-05 20:25 ` Christophe Lyon
0 siblings, 0 replies; 20+ messages in thread
From: Christophe Lyon @ 2015-01-05 20:25 UTC (permalink / raw)
To: David Abdurachmanov
Cc: Andrew Pinski, Jakub Jelinek, Dmitry Vyukov,
Konstantin Serebryany, GCC Patches, Dodji Seketeli,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
On 31 December 2014 at 13:29, David Abdurachmanov
<david.abdurachmanov@gmail.com> wrote:
>
> On Dec 30, 2014, at 11:48 PM, Andrew Pinski wrote:
>>> If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
>>> used for getresuid syscall, otherwise if 32-bit application is executed --
>>> sys_getresuid16 is used. Thus 64-bit application will never call
>>> sys_getresuid16 implemenation. Then
>>> getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
>>> binary of libsanitizer. Same should apply for x86_64/i*86.
>>>
>>> Is that correct?
>>
>> Kinda. It only applies for aarch32 and not for AARCH64:ILP32.
>> AARCH64:ILP32 uses the standard system calls here too.
>
>
> I am attaching an updated patch, bootstrapped trunk on arrch64 with kernels 3.12 and 3.17 (QEMU).
>
> I looked at kernel source. If CONFIG_COMPAT is set then CONFIG_HAVE_UID16 is set.
Thanks for taking care of this.
>
> From include/linux/syscalls.h
>
> 523 #ifdef CONFIG_UID16
> 524 asmlinkage long sys_chown16(const char __user *filename,
> 525 old_uid_t user, old_gid_t group);
> 526 asmlinkage long sys_lchown16(const char __user *filename,
> 527 old_uid_t user, old_gid_t group);
> 528 asmlinkage long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t group);
> 529 asmlinkage long sys_setregid16(old_gid_t rgid, old_gid_t egid);
> 530 asmlinkage long sys_setgid16(old_gid_t gid);
> 531 asmlinkage long sys_setreuid16(old_uid_t ruid, old_uid_t euid);
> 532 asmlinkage long sys_setuid16(old_uid_t uid);
> 533 asmlinkage long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t suid);
> 534 asmlinkage long sys_getresuid16(old_uid_t __user *ruid,
> 535 old_uid_t __user *euid, old_uid_t __user *suid);
> 536 asmlinkage long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t sgid);
> 537 asmlinkage long sys_getresgid16(old_gid_t __user *rgid,
> 538 old_gid_t __user *egid, old_gid_t __user *sgid);
> 539 asmlinkage long sys_setfsuid16(old_uid_t uid);
> 540 asmlinkage long sys_setfsgid16(old_gid_t gid);
> 541 asmlinkage long sys_getgroups16(int gidsetsize, old_gid_t __user *grouplist);
> 542 asmlinkage long sys_setgroups16(int gidsetsize, old_gid_t __user *grouplist);
> 543 asmlinkage long sys_getuid16(void);
> 544 asmlinkage long sys_geteuid16(void);
> 545 asmlinkage long sys_getgid16(void);
> 546 asmlinkage long sys_getegid16(void);
> 547 #endif
>
> Thus I disabled such syscalls in libsanitizer with SANITIZER_WORDSIZE macro and disabled
> type checks for __kernel_old_{uid,gid}_t. Did not touch the fragment which sets
> __kernel_old_{uid,gid}_t.
>
> SANITIZER_WORDSIZE is set based on _LP64 macro.
>
> If patch is acceptable I could do more tests after holidays.
>
As it seems you are not aware of it, and the llvm guys haven't yet
told you: these patches need to be approved in the upstream
sanitizer/llvm repo, and they will be merge into gcc later. So I
believe you need to send your patches to llvm first.
Thanks,
Christophe.
> Thanks,
> david
>
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-12-30 22:49 ` Andrew Pinski
@ 2014-12-31 12:36 ` David Abdurachmanov
2015-01-05 20:25 ` Christophe Lyon
0 siblings, 1 reply; 20+ messages in thread
From: David Abdurachmanov @ 2014-12-31 12:36 UTC (permalink / raw)
To: Andrew Pinski, Jakub Jelinek, Dmitry Vyukov,
Konstantin Serebryany, GCC Patches, Dodji Seketeli,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
[-- Attachment #1: Type: text/plain, Size: 2708 bytes --]
On Dec 30, 2014, at 11:48 PM, Andrew Pinski wrote:
>> If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
>> used for getresuid syscall, otherwise if 32-bit application is executed --
>> sys_getresuid16 is used. Thus 64-bit application will never call
>> sys_getresuid16 implemenation. Then
>> getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
>> binary of libsanitizer. Same should apply for x86_64/i*86.
>>
>> Is that correct?
>
> Kinda. It only applies for aarch32 and not for AARCH64:ILP32.
> AARCH64:ILP32 uses the standard system calls here too.
I am attaching an updated patch, bootstrapped trunk on arrch64 with kernels 3.12 and 3.17 (QEMU).
I looked at kernel source. If CONFIG_COMPAT is set then CONFIG_HAVE_UID16 is set.
From include/linux/syscalls.h
523 #ifdef CONFIG_UID16
524 asmlinkage long sys_chown16(const char __user *filename,
525 old_uid_t user, old_gid_t group);
526 asmlinkage long sys_lchown16(const char __user *filename,
527 old_uid_t user, old_gid_t group);
528 asmlinkage long sys_fchown16(unsigned int fd, old_uid_t user, old_gid_t group);
529 asmlinkage long sys_setregid16(old_gid_t rgid, old_gid_t egid);
530 asmlinkage long sys_setgid16(old_gid_t gid);
531 asmlinkage long sys_setreuid16(old_uid_t ruid, old_uid_t euid);
532 asmlinkage long sys_setuid16(old_uid_t uid);
533 asmlinkage long sys_setresuid16(old_uid_t ruid, old_uid_t euid, old_uid_t suid);
534 asmlinkage long sys_getresuid16(old_uid_t __user *ruid,
535 old_uid_t __user *euid, old_uid_t __user *suid);
536 asmlinkage long sys_setresgid16(old_gid_t rgid, old_gid_t egid, old_gid_t sgid);
537 asmlinkage long sys_getresgid16(old_gid_t __user *rgid,
538 old_gid_t __user *egid, old_gid_t __user *sgid);
539 asmlinkage long sys_setfsuid16(old_uid_t uid);
540 asmlinkage long sys_setfsgid16(old_gid_t gid);
541 asmlinkage long sys_getgroups16(int gidsetsize, old_gid_t __user *grouplist);
542 asmlinkage long sys_setgroups16(int gidsetsize, old_gid_t __user *grouplist);
543 asmlinkage long sys_getuid16(void);
544 asmlinkage long sys_geteuid16(void);
545 asmlinkage long sys_getgid16(void);
546 asmlinkage long sys_getegid16(void);
547 #endif
Thus I disabled such syscalls in libsanitizer with SANITIZER_WORDSIZE macro and disabled
type checks for __kernel_old_{uid,gid}_t. Did not touch the fragment which sets
__kernel_old_{uid,gid}_t.
SANITIZER_WORDSIZE is set based on _LP64 macro.
If patch is acceptable I could do more tests after holidays.
Thanks,
david
[-- Attachment #2: pr64435v2.patch --]
[-- Type: application/octet-stream, Size: 2801 bytes --]
diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index 8b2eb82..8858803 100644
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,3 +1,29 @@
+2014-12-31 David Abdurachmanov <davidlt@cern.ch>
+
+ PR sanitizer/64435
+ * sanitizer_common/sanitizer_common_syscalls.inc (chown16): Disable on
+ LP64 targets.
+ (lchown16): Likewise.
+ (fchown16): Likewise.
+ (setregid16): Likewise.
+ (setgid16): Likewise.
+ (setreuid16): Likewise.
+ (setuid16): Likewise.
+ (setresuid16): Likewise.
+ (getresuid16): Likewise.
+ (setresgid16): Likewise.
+ (getresgid16): Likewise.
+ (setfsuid16): Likewise.
+ (setfsgid16): Likewise.
+ (getgroups16): Likewise.
+ (setgroups16): Likewise.
+ (getuid16): Likewise.
+ (geteuid16): Likewise.
+ (getgid16): Likewise.
+ (getegid16): Likewise.
+ * sanitizer_common/sanitizer_platform_limits_posix.cc: Disable
+ CHECK_TYPE_SIZE for __kernel_old_{uid,gid}_t on LP64 targets.
+
2014-12-16 Jakub Jelinek <jakub@redhat.com>
* sanitizer_common/sanitizer_symbolizer_libbacktrace.cc,
diff --git a/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc b/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
index 24e1b7e..cd2b76c 100644
--- a/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
+++ b/libsanitizer/sanitizer_common/sanitizer_common_syscalls.inc
@@ -1441,6 +1441,12 @@ PRE_SYSCALL(fchown)(long fd, long user, long group) {}
POST_SYSCALL(fchown)(long res, long fd, long user, long group) {}
+// Syscalls below are only available on 64-bit target if CONFIG_COMPAT
+// (which enables CONFIG_HAVE_UID16) is selected in kernel defconfig.
+// These syscalls implementations are needed for 32-bit (compat)
+// applications on 64-bit target. They will not be used by 64-bit
+// applications.
+#if SANITIZER_WORDSIZE == 32
PRE_SYSCALL(chown16)(const void *filename, long user, long group) {
if (filename)
PRE_READ(filename,
@@ -1550,6 +1556,7 @@ POST_SYSCALL(getgid16)(long res) {}
PRE_SYSCALL(getegid16)() {}
POST_SYSCALL(getegid16)(long res) {}
+#endif // SANITIZER_WORDSIZE == 32
PRE_SYSCALL(utime)(void *filename, void *times) {}
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
index 13d908e..b389690 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc
@@ -1003,8 +1003,10 @@ CHECK_SIZE_AND_OFFSET(__sysctl_args, newlen);
CHECK_TYPE_SIZE(__kernel_uid_t);
CHECK_TYPE_SIZE(__kernel_gid_t);
+#if SANITIZER_WORDSIZE == 32
CHECK_TYPE_SIZE(__kernel_old_uid_t);
CHECK_TYPE_SIZE(__kernel_old_gid_t);
+#endif
CHECK_TYPE_SIZE(__kernel_off_t);
CHECK_TYPE_SIZE(__kernel_loff_t);
CHECK_TYPE_SIZE(__kernel_fd_set);
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-12-30 22:48 ` David Abdurachmanov
@ 2014-12-30 22:49 ` Andrew Pinski
2014-12-31 12:36 ` David Abdurachmanov
0 siblings, 1 reply; 20+ messages in thread
From: Andrew Pinski @ 2014-12-30 22:49 UTC (permalink / raw)
To: David Abdurachmanov
Cc: Jakub Jelinek, Dmitry Vyukov, Konstantin Serebryany, GCC Patches,
Dodji Seketeli, Marek Polacek, H.J. Lu, Yuri Gribov,
Alexey Samsonov
On Tue, Dec 30, 2014 at 2:39 PM, David Abdurachmanov
<david.abdurachmanov@gmail.com> wrote:
>
> On Dec 29, 2014, at 7:46 PM, Jakub Jelinek wrote:
>
>> On Mon, Dec 29, 2014 at 07:36:42PM +0100, David Abdurachmanov wrote:
>>> I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15,
>>> 3.16 and above are fine.
>>>
>>> __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
>>> short. <=3.15 kernel will trigger static asserts in libsanitizer while
>>> compiling GCC.
>>>
>>> I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
>>> the details).
>>>
>>> Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
>>> in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.
>>
>> That looks very much wrong, ABI can't depend on what kernel headers you are
>> compiling against.
>> So, better would be just to ifdef out the check and always use 16-bit
>> __kernel_old_*_t on aarch64. Are the
>> getresuid16/getresgid16/getgroups16/setgroups16 syscalls wired at all on
>> aarch64? If not, then supposedly the sanitizer_common_syscalls.inc stuff
>> for these syscalls should be ifdefed out on aarch64 (or any other arch that
>> doesn't have those syscalls).
>
> I am not an expert here.
>
> # uname -r -m
> 3.17.0-301.fc21.aarch64 aarch64
>
> # cat /proc/kallsyms | sed -n 's/.* sys_//p' | grep 16
> chown16
> fchown16
> getegid16
> geteuid16
> getgid16
> getgroups16
> getresgid16
> getresuid16
> getuid16
> lchown16
> setfsgid16
> setfsuid16
> setgid16
> setgroups16
> setregid16
> setresgid16
> setresuid16
> setreuid16
> setuid16
>
> The following are syscall implementations available in my current kernel with
> "16" suffix.
>
> From include/uapi/asm-generic/unistd.h
>
> 435 #define __NR_getresuid 148
> 436 __SYSCALL(__NR_getresuid, sys_getresuid)
>
> From arch/arm64/include/asm/unistd32.h
>
> 354 #define __NR_getresuid 165
> 355 __SYSCALL(__NR_getresuid, sys_getresuid16)
>
> Isn't this needed for 32-bit (compat) application support on 64-bit system?
>
> https://lkml.org/lkml/2012/7/6/570
> https://lkml.org/lkml/2012/7/6/545
>
> If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
> used for getresuid syscall, otherwise if 32-bit application is executed --
> sys_getresuid16 is used. Thus 64-bit application will never call
> sys_getresuid16 implemenation. Then
> getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
> binary of libsanitizer. Same should apply for x86_64/i*86.
>
> Is that correct?
Kinda. It only applies for aarch32 and not for AARCH64:ILP32.
AARCH64:ILP32 uses the standard system calls here too.
Thanks,
Andrew Pinski
>
> david
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-12-29 20:03 ` Jakub Jelinek
@ 2014-12-30 22:48 ` David Abdurachmanov
2014-12-30 22:49 ` Andrew Pinski
0 siblings, 1 reply; 20+ messages in thread
From: David Abdurachmanov @ 2014-12-30 22:48 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Dmitry Vyukov, Konstantin Serebryany, GCC Patches,
Dodji Seketeli, Marek Polacek, H.J. Lu, Yuri Gribov,
Alexey Samsonov
[-- Attachment #1: Type: text/plain, Size: 2433 bytes --]
On Dec 29, 2014, at 7:46 PM, Jakub Jelinek wrote:
> On Mon, Dec 29, 2014 at 07:36:42PM +0100, David Abdurachmanov wrote:
>> I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15,
>> 3.16 and above are fine.
>>
>> __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
>> short. <=3.15 kernel will trigger static asserts in libsanitizer while
>> compiling GCC.
>>
>> I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
>> the details).
>>
>> Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
>> in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.
>
> That looks very much wrong, ABI can't depend on what kernel headers you are
> compiling against.
> So, better would be just to ifdef out the check and always use 16-bit
> __kernel_old_*_t on aarch64. Are the
> getresuid16/getresgid16/getgroups16/setgroups16 syscalls wired at all on
> aarch64? If not, then supposedly the sanitizer_common_syscalls.inc stuff
> for these syscalls should be ifdefed out on aarch64 (or any other arch that
> doesn't have those syscalls).
I am not an expert here.
# uname -r -m
3.17.0-301.fc21.aarch64 aarch64
# cat /proc/kallsyms | sed -n 's/.* sys_//p' | grep 16
chown16
fchown16
getegid16
geteuid16
getgid16
getgroups16
getresgid16
getresuid16
getuid16
lchown16
setfsgid16
setfsuid16
setgid16
setgroups16
setregid16
setresgid16
setresuid16
setreuid16
setuid16
The following are syscall implementations available in my current kernel with
"16" suffix.
From include/uapi/asm-generic/unistd.h
435 #define __NR_getresuid 148
436 __SYSCALL(__NR_getresuid, sys_getresuid)
From arch/arm64/include/asm/unistd32.h
354 #define __NR_getresuid 165
355 __SYSCALL(__NR_getresuid, sys_getresuid16)
Isn't this needed for 32-bit (compat) application support on 64-bit system?
https://lkml.org/lkml/2012/7/6/570
https://lkml.org/lkml/2012/7/6/545
If we have 64-bit kernel and 64-bit application is executed sys_getresuid is
used for getresuid syscall, otherwise if 32-bit application is executed --
sys_getresuid16 is used. Thus 64-bit application will never call
sys_getresuid16 implemenation. Then
getresuid16/getresgid16/getgroups16/setgroups16/etc only needs to in 32-bit
binary of libsanitizer. Same should apply for x86_64/i*86.
Is that correct?
david
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-12-29 18:36 ` David Abdurachmanov
@ 2014-12-29 20:03 ` Jakub Jelinek
2014-12-30 22:48 ` David Abdurachmanov
0 siblings, 1 reply; 20+ messages in thread
From: Jakub Jelinek @ 2014-12-29 20:03 UTC (permalink / raw)
To: David Abdurachmanov
Cc: Dmitry Vyukov, Konstantin Serebryany, GCC Patches,
Dodji Seketeli, Marek Polacek, H.J. Lu, Yuri Gribov,
Alexey Samsonov
On Mon, Dec 29, 2014 at 07:36:42PM +0100, David Abdurachmanov wrote:
> I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15,
> 3.16 and above are fine.
>
> __kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
> short. <=3.15 kernel will trigger static asserts in libsanitizer while
> compiling GCC.
>
> I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
> the details).
>
> Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
> in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.
That looks very much wrong, ABI can't depend on what kernel headers you are
compiling against.
So, better would be just to ifdef out the check and always use 16-bit
__kernel_old_*_t on aarch64. Are the
getresuid16/getresgid16/getgroups16/setgroups16 syscalls wired at all on
aarch64? If not, then supposedly the sanitizer_common_syscalls.inc stuff
for these syscalls should be ifdefed out on aarch64 (or any other arch that
doesn't have those syscalls).
Jakub
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-21 12:24 ` Dmitry Vyukov
2014-12-29 18:36 ` David Abdurachmanov
@ 2014-12-29 18:44 ` David Abdurachmanov
1 sibling, 0 replies; 20+ messages in thread
From: David Abdurachmanov @ 2014-12-29 18:44 UTC (permalink / raw)
To: Dmitry Vyukov, Jakub Jelinek, Konstantin Serebryany, GCC Patches,
Dodji Seketeli, Marek Polacek, H.J. Lu, Yuri Gribov,
Alexey Samsonov
[-- Attachment #1.1: Type: text/plain, Size: 532 bytes --]
Hi,
I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15,
3.16 and above are fine.
__kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
short. <=3.15 kernel will trigger static asserts in libsanitizer while
compiling GCC.
I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
the details).
Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.
david
[-- Attachment #1.2: gcc-pr64435.patch --]
[-- Type: application/octet-stream, Size: 1508 bytes --]
diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index 8b2eb82..8e5aaa0 100644
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,3 +1,10 @@
+2014-12-29 David Abdurachmanov <davidlt@cern.ch>
+
+ PR sanitizer/64435
+ * sanitizer_common/sanitizer_platform_limits_posix.h: Include linux/version.h
+ for Linux, set __sanitizer___kernel_old_{uid,gid}_t to unsigned int for
+ <=3.15 kernel.
+
2014-12-16 Jakub Jelinek <jakub@redhat.com>
* sanitizer_common/sanitizer_symbolizer_libbacktrace.cc,
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 139fe0a..0cc3c3e 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -16,6 +16,10 @@
#include "sanitizer_internal_defs.h"
#include "sanitizer_platform.h"
+#if SANITIZER_LINUX
+#include <linux/version.h>
+#endif
+
namespace __sanitizer {
extern unsigned struct_utsname_sz;
extern unsigned struct_stat_sz;
@@ -470,7 +474,9 @@ namespace __sanitizer {
typedef long __sanitizer___kernel_off_t;
#endif
-#if defined(__powerpc__) || defined(__mips__)
+#if defined(__powerpc__) || defined(__mips__) \
+ || (defined(__aarch64__) && SANITIZER_LINUX \
+ && LINUX_VERSION_CODE <= KERNEL_VERSION(3, 15, 0))
typedef unsigned int __sanitizer___kernel_old_uid_t;
typedef unsigned int __sanitizer___kernel_old_gid_t;
#else
[-- Attachment #1.3: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-21 12:24 ` Dmitry Vyukov
@ 2014-12-29 18:36 ` David Abdurachmanov
2014-12-29 20:03 ` Jakub Jelinek
2014-12-29 18:44 ` David Abdurachmanov
1 sibling, 1 reply; 20+ messages in thread
From: David Abdurachmanov @ 2014-12-29 18:36 UTC (permalink / raw)
To: Dmitry Vyukov, Jakub Jelinek, Konstantin Serebryany, GCC Patches,
Dodji Seketeli, Marek Polacek, H.J. Lu, Yuri Gribov,
Alexey Samsonov
[-- Attachment #1.1: Type: text/plain, Size: 532 bytes --]
Hi,
I believe this is breaking bootstrap on aarch64-linux-gnu with kernels <=3.15,
3.16 and above are fine.
__kernel_old_{gid,uid}_t were changed in 3.16 from unsigned int to unsigned
short. <=3.15 kernel will trigger static asserts in libsanitizer while
compiling GCC.
I created PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64435 (includes all
the details).
Attaching a patch with resolved issues on F19 + 3.12 kernel (also bootstrapped
in QEMU with F21 rootfs + 3.17 kernel) on aarch64-linux-gnu.
david
[-- Attachment #1.2: gcc-pr64435.patch --]
[-- Type: application/octet-stream, Size: 1508 bytes --]
diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index 8b2eb82..8e5aaa0 100644
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,3 +1,10 @@
+2014-12-29 David Abdurachmanov <davidlt@cern.ch>
+
+ PR sanitizer/64435
+ * sanitizer_common/sanitizer_platform_limits_posix.h: Include linux/version.h
+ for Linux, set __sanitizer___kernel_old_{uid,gid}_t to unsigned int for
+ <=3.15 kernel.
+
2014-12-16 Jakub Jelinek <jakub@redhat.com>
* sanitizer_common/sanitizer_symbolizer_libbacktrace.cc,
diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
index 139fe0a..0cc3c3e 100644
--- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
+++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h
@@ -16,6 +16,10 @@
#include "sanitizer_internal_defs.h"
#include "sanitizer_platform.h"
+#if SANITIZER_LINUX
+#include <linux/version.h>
+#endif
+
namespace __sanitizer {
extern unsigned struct_utsname_sz;
extern unsigned struct_stat_sz;
@@ -470,7 +474,9 @@ namespace __sanitizer {
typedef long __sanitizer___kernel_off_t;
#endif
-#if defined(__powerpc__) || defined(__mips__)
+#if defined(__powerpc__) || defined(__mips__) \
+ || (defined(__aarch64__) && SANITIZER_LINUX \
+ && LINUX_VERSION_CODE <= KERNEL_VERSION(3, 15, 0))
typedef unsigned int __sanitizer___kernel_old_uid_t;
typedef unsigned int __sanitizer___kernel_old_gid_t;
#else
[-- Attachment #1.3: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-13 9:16 ` Jakub Jelinek
2014-11-13 20:49 ` Konstantin Serebryany
@ 2014-11-21 12:24 ` Dmitry Vyukov
2014-12-29 18:36 ` David Abdurachmanov
2014-12-29 18:44 ` David Abdurachmanov
1 sibling, 2 replies; 20+ messages in thread
From: Dmitry Vyukov @ 2014-11-21 12:24 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Konstantin Serebryany, GCC Patches, Dodji Seketeli,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-14 15:51 ` Christophe Lyon
@ 2014-11-14 17:00 ` Konstantin Serebryany
0 siblings, 0 replies; 20+ messages in thread
From: Konstantin Serebryany @ 2014-11-14 17:00 UTC (permalink / raw)
To: Christophe Lyon, Evgeniy Stepanov
Cc: Jakub Jelinek, GCC Patches, Dodji Seketeli, Dmitry Vyukov,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
+eugenis (what kind of testing on ARM are we doing upstream?)
On Fri, Nov 14, 2014 at 7:44 AM, Christophe Lyon
<christophe.lyon@linaro.org> wrote:
> On 14 November 2014 11:38, Christophe Lyon <christophe.lyon@linaro.org> wrote:
>> On 13 November 2014 21:44, Konstantin Serebryany
>> <konstantin.s.serebryany@gmail.com> wrote:
>>> On Thu, Nov 13, 2014 at 1:16 AM, 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.
>>>
>>> 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.
>>
>
> Hi again,
>
> Looking at the results on ARM platforms, I've noticed regressions when
> the compiler generates code in Thumb mode (as opposed to ARM mode).
> The backtraces are incomplete, thus making the tests fail.
>
> For instance, in heap-overflow-1.c, we had:
> #0 0x408c2207 in __interceptor_malloc
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libsanitizer/asan/asan_malloc_linux.cc:38^M
> #1 0x888b in main
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:19^M
>
> and now:
> #0 0x408c1eff in __interceptor_malloc
> /aci-gcc-fsf/sources/gcc-fsf/gccsrc/libsanitizer/asan/asan_malloc_linux.cc:38^M
> #1 0x407fcb83 (<unknown module>)^M
>
> I'm not familiar with LLVM+sanitizer testing: what kind of tests are
> performed upstream before committing changes?
> Do both ARM & Thumb modes pass LLVM+sanitizer tests?
Evgenyi can answer that, I hope.
Christophe, I encourage you to add more ARM testing to LLVM build bots.
> Do they check
> backtraces as in GCC testsuite?
>
>
>
>>>
>>>>
>>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-14 16:53 ` Konstantin Serebryany
@ 2014-11-14 16:57 ` Konstantin Serebryany
0 siblings, 0 replies; 20+ messages in thread
From: Konstantin Serebryany @ 2014-11-14 16:57 UTC (permalink / raw)
To: Christophe Lyon
Cc: Jakub Jelinek, GCC Patches, Dodji Seketeli, Dmitry Vyukov,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
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.serebryany@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.lyon@linaro.org> wrote:
>> On 13 November 2014 21:44, Konstantin Serebryany
>> <konstantin.s.serebryany@gmail.com> wrote:
>>> On Thu, Nov 13, 2014 at 1:16 AM, 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.
>>>
>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-14 10:44 ` Christophe Lyon
2014-11-14 15:51 ` Christophe Lyon
@ 2014-11-14 16:53 ` Konstantin Serebryany
2014-11-14 16:57 ` Konstantin Serebryany
1 sibling, 1 reply; 20+ messages in thread
From: Konstantin Serebryany @ 2014-11-14 16:53 UTC (permalink / raw)
To: Christophe Lyon
Cc: Jakub Jelinek, GCC Patches, Dodji Seketeli, Dmitry Vyukov,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
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.lyon@linaro.org> wrote:
> On 13 November 2014 21:44, Konstantin Serebryany
> <konstantin.s.serebryany@gmail.com> wrote:
>> On Thu, Nov 13, 2014 at 1:16 AM, 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.
>>
>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-14 10:44 ` Christophe Lyon
@ 2014-11-14 15:51 ` Christophe Lyon
2014-11-14 17:00 ` Konstantin Serebryany
2014-11-14 16:53 ` Konstantin Serebryany
1 sibling, 1 reply; 20+ messages in thread
From: Christophe Lyon @ 2014-11-14 15:51 UTC (permalink / raw)
To: Konstantin Serebryany
Cc: Jakub Jelinek, GCC Patches, Dodji Seketeli, Dmitry Vyukov,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
On 14 November 2014 11:38, Christophe Lyon <christophe.lyon@linaro.org> wrote:
> On 13 November 2014 21:44, Konstantin Serebryany
> <konstantin.s.serebryany@gmail.com> wrote:
>> On Thu, Nov 13, 2014 at 1:16 AM, 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.
>>
>> 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.
>
Hi again,
Looking at the results on ARM platforms, I've noticed regressions when
the compiler generates code in Thumb mode (as opposed to ARM mode).
The backtraces are incomplete, thus making the tests fail.
For instance, in heap-overflow-1.c, we had:
#0 0x408c2207 in __interceptor_malloc
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libsanitizer/asan/asan_malloc_linux.cc:38^M
#1 0x888b in main
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/testsuite/c-c++-common/asan/heap-overflow-1.c:19^M
and now:
#0 0x408c1eff in __interceptor_malloc
/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libsanitizer/asan/asan_malloc_linux.cc:38^M
#1 0x407fcb83 (<unknown module>)^M
I'm not familiar with LLVM+sanitizer testing: what kind of tests are
performed upstream before committing changes?
Do both ARM & Thumb modes pass LLVM+sanitizer tests? Do they check
backtraces as in GCC testsuite?
>>
>>>
>>> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-13 20:49 ` Konstantin Serebryany
@ 2014-11-14 10:44 ` Christophe Lyon
2014-11-14 15:51 ` Christophe Lyon
2014-11-14 16:53 ` Konstantin Serebryany
0 siblings, 2 replies; 20+ messages in thread
From: Christophe Lyon @ 2014-11-14 10:44 UTC (permalink / raw)
To: Konstantin Serebryany
Cc: Jakub Jelinek, GCC Patches, Dodji Seketeli, Dmitry Vyukov,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
On 13 November 2014 21:44, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> On Thu, Nov 13, 2014 at 1:16 AM, 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.
>
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-13 9:16 ` Jakub Jelinek
@ 2014-11-13 20:49 ` Konstantin Serebryany
2014-11-14 10:44 ` Christophe Lyon
2014-11-21 12:24 ` Dmitry Vyukov
1 sibling, 1 reply; 20+ messages in thread
From: Konstantin Serebryany @ 2014-11-13 20:49 UTC (permalink / raw)
To: Jakub Jelinek
Cc: GCC Patches, Dodji Seketeli, Dmitry Vyukov, Marek Polacek,
H.J. Lu, Yuri Gribov, Alexey Samsonov
On Thu, Nov 13, 2014 at 1:16 AM, 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.
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.
>
> 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
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-13 1:45 Konstantin Serebryany
2014-11-13 9:16 ` Jakub Jelinek
@ 2014-11-13 14:45 ` Jack Howarth
1 sibling, 0 replies; 20+ messages in thread
From: Jack Howarth @ 2014-11-13 14:45 UTC (permalink / raw)
To: GCC Patches, Konstantin Serebryany
Konstantin,
Applying the libsanitizer-221802.patch merge to r217456 with
the proposed patch at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50, produces the
following new regressions on x86_64-apple-darwin14 for asan.exp at
-m32/-m64...
FAIL: c-c++-common/asan/global-overflow-1.c -O0 output pattern
test, is =================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -O1 output pattern
test, is =================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -O2 output pattern
test, is =================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -O3 -fomit-frame-pointer
output pattern test, is
=================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -O3 -g output pattern
test, is =================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -Os output pattern
test, is =================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto
-flto-partition=none output pattern test, is
=================================================================
FAIL: c-c++-common/asan/global-overflow-1.c -O2 -flto output
pattern test, is
=================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O0 output pattern test,
is =================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O1 output pattern test,
is =================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O2 output pattern test,
is =================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -fomit-frame-pointer
output pattern test, is
=================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O3 -g output pattern
test, is =================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -Os output pattern test,
is =================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto
-flto-partition=none output pattern test, is
=================================================================
FAIL: c-c++-common/asan/heap-overflow-1.c -O2 -flto output pattern
test, is =================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O0 output pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O1 output pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O2 output pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O3 -fomit-frame-pointer output
pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O3 -g output pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -Os output pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O2 -flto -flto-partition=none
output pattern test, is
=================================================================
FAIL: c-c++-common/asan/memcmp-1.c -O2 -flto output pattern test,
is =================================================================
FAIL: g++.dg/asan/deep-stack-uaf-1.C -O0 output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-stack-uaf-1.C -O1 output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-stack-uaf-1.C -O2 output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-stack-uaf-1.C -O3 -fomit-frame-pointer output
pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-stack-uaf-1.C -O3 -g output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-stack-uaf-1.C -Os output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O0 output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O1 output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O2 output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O3 -fomit-frame-pointer output
pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O3 -g output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -Os output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O2 -flto -flto-partition=none
output pattern test, is
=================================================================
FAIL: g++.dg/asan/deep-tail-call-1.C -O2 -flto output pattern test,
is =================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O0 output pattern test, is
=================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O1 output pattern test, is
=================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O2 output pattern test, is
=================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O3 -fomit-frame-pointer
output pattern test, is
=================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O3 -g output pattern test,
is =================================================================
FAIL: g++.dg/asan/large-func-test-1.C -Os output pattern test, is
=================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O2 -flto -flto-partition=none
output pattern test, is
=================================================================
FAIL: g++.dg/asan/large-func-test-1.C -O2 -flto output pattern
test, is =================================================================
beyond those previously observed
inhttps://gcc.gnu.org/ml/gcc-testresults/2014-11/msg01024.html.
On Wed, Nov 12, 2014 at 8:35 PM, Konstantin Serebryany
<konstantin.s.serebryany@gmail.com> wrote:
> Hi,
>
> 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.
> * asan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
> * 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.
> * 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.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: libsanitizer merge from upstream r221802
2014-11-13 1:45 Konstantin Serebryany
@ 2014-11-13 9:16 ` Jakub Jelinek
2014-11-13 20:49 ` Konstantin Serebryany
2014-11-21 12:24 ` Dmitry Vyukov
2014-11-13 14:45 ` Jack Howarth
1 sibling, 2 replies; 20+ messages in thread
From: Jakub Jelinek @ 2014-11-13 9:16 UTC (permalink / raw)
To: Konstantin Serebryany
Cc: GCC Patches, Dodji Seketeli, Dmitry Vyukov, Marek Polacek,
H.J. Lu, Yuri Gribov, Alexey Samsonov
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.
Jakub
^ permalink raw reply [flat|nested] 20+ messages in thread
* libsanitizer merge from upstream r221802
@ 2014-11-13 1:45 Konstantin Serebryany
2014-11-13 9:16 ` Jakub Jelinek
2014-11-13 14:45 ` Jack Howarth
0 siblings, 2 replies; 20+ messages in thread
From: Konstantin Serebryany @ 2014-11-13 1:45 UTC (permalink / raw)
To: GCC Patches, Jakub Jelinek, Dodji Seketeli, Dmitry Vyukov,
Marek Polacek, H.J. Lu, Yuri Gribov, Alexey Samsonov
[-- Attachment #1: Type: text/plain, Size: 1578 bytes --]
Hi,
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.
* asan/Makefile.am (AM_CXXFLAGS): added -std=c++11.
* 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.
* 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.
[-- Attachment #2: libsanitizer-221802.patch.gz --]
[-- Type: application/x-gzip, Size: 53739 bytes --]
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2015-01-05 20:25 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-11-14 11:41 libsanitizer merge from upstream r221802 Uros Bizjak
2014-11-14 14:35 ` Uros Bizjak
2014-11-14 14:48 ` Jakub Jelinek
-- strict thread matches above, loose matches on Subject: below --
2014-11-13 1:45 Konstantin Serebryany
2014-11-13 9:16 ` Jakub Jelinek
2014-11-13 20:49 ` Konstantin Serebryany
2014-11-14 10:44 ` Christophe Lyon
2014-11-14 15:51 ` Christophe Lyon
2014-11-14 17:00 ` Konstantin Serebryany
2014-11-14 16:53 ` Konstantin Serebryany
2014-11-14 16:57 ` Konstantin Serebryany
2014-11-21 12:24 ` Dmitry Vyukov
2014-12-29 18:36 ` David Abdurachmanov
2014-12-29 20:03 ` Jakub Jelinek
2014-12-30 22:48 ` David Abdurachmanov
2014-12-30 22:49 ` Andrew Pinski
2014-12-31 12:36 ` David Abdurachmanov
2015-01-05 20:25 ` Christophe Lyon
2014-12-29 18:44 ` David Abdurachmanov
2014-11-13 14:45 ` Jack Howarth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).