Roll Clang 214024:216630 (+216684) and switch to CMake

Roll Clang 214024:216630 (+216684) and switch to CMake

This updates Chromium's clang version to r216630 with
r216684 cherry-picked to fix an ASan issue.

It also changes the build script for Clang to use CMake
instead of Autoconf. The ASan team say this configuration
is better tested, and it also makes us consistent with
the Windows Clang build which already uses CMake.

BUG=400849
R=thakis@chromium.org

Committed: https://chromium.googlesource.com/chromium/src/+/ff31c1ba254ca37f7a8b45549e1b7b1c978b3390

[hans, 2014-08-08 00:54:27]

Nico: would you mind taking a look at this on Mac? I've gotten to the stage
where it's failing with:


[1483/2675] Linking CXX shared library lib/libc++.1.0.dylib
FAILED: : &&
/work/chromium/src/tools/clang/scripts/../../../third_party/llvm/../llvm-bootstrap-install/bin/clang++
-nostdinc++
-I/work/chromium/src/tools/clang/scripts/../../../third_party/llvm/projects/libcxx/include
-isysroot /Appl
ications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-fPIC -fvisibility-inlin
es-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wmissing-field-initializers -pedantic -Wno-long-long -Wcover
ed-switch-default -Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -nostdinc++
-std=c++0x -Werror=return-type -Wall -
W -Wno-unused-parameter -Wwrite-strings -Wno-long-long -Wno-error -pedantic
-D_DEBUG -UNDEBUG -O3   -dynamiclib -Wl,-h
eaderpad_max_install_names -stdlib=libc++
-L/work/chromium/src/third_party/llvm-build/Release+Asserts/libcxxbuild  -no
defaultlibs -compatibility_version 1 -install_name /usr/lib/libc++.1.dylib
-Wl,-unexported_symbols_list,/work/chromium
/src/third_party/llvm/projects/libcxx/lib/libc++unexp.exp
/usr/lib/libc++abi.dylib -Wl,-reexported_symbols_list,/work/
chromium/src/third_party/llvm/projects/libcxx/lib/libc++abi.exp
-Wl,-force_symbols_not_weak_list,/work/chromium/src/th
ird_party/llvm/projects/libcxx/lib/notweak.exp
-Wl,-force_symbols_weak_list,/work/chromium/src/third_party/llvm/projec
ts/libcxx/lib/weak.exp -o lib/libc++.1.0.dylib -install_name
@rpath/libc++.1.dylib projects/libcxx/lib/CMakeFiles/cxx.
dir/__/src/algorithm.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/bind.cpp.o
projects/libcxx/lib/CMakeFiles/cxx
.dir/__/src/chrono.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/condition_variable.cpp.o
projects/libcxx/lib/CM
akeFiles/cxx.dir/__/src/debug.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/exception.cpp.o
projects/libcxx/lib/
CMakeFiles/cxx.dir/__/src/future.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/hash.cpp.o projects/libcxx/lib/CM
akeFiles/cxx.dir/__/src/ios.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/iostream.cpp.o
projects/libcxx/lib/CMa
keFiles/cxx.dir/__/src/locale.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/memory.cpp.o
projects/libcxx/lib/CMa
keFiles/cxx.dir/__/src/mutex.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/new.cpp.o
projects/libcxx/lib/CMakeFi
les/cxx.dir/__/src/optional.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/random.cpp.o
projects/libcxx/lib/CMake
Files/cxx.dir/__/src/regex.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/shared_mutex.cpp.o
projects/libcxx/lib/
CMakeFiles/cxx.dir/__/src/stdexcept.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/string.cpp.o projects/libcxx/l
ib/CMakeFiles/cxx.dir/__/src/strstream.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/system_error.cpp.o projects
/libcxx/lib/CMakeFiles/cxx.dir/__/src/thread.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/typeinfo.cpp.o projec
ts/libcxx/lib/CMakeFiles/cxx.dir/__/src/utility.cpp.o
projects/libcxx/lib/CMakeFiles/cxx.dir/__/src/valarray.cpp.o  -l
pthread -lc -lm -Wl,-rpath,@executable_path/../lib && :
clang-3.5: warning: argument unused during compilation: '-nostdinc++'
clang-3.5: warning: argument unused during compilation: '-nostdinc++'
ld: targeted OS version does not support -reexported_symbols_list
clang-3.5: error: linker command failed with exit code 1 (use -v to see
invocation)
ninja: build stopped: subcommand failed.

[hans, 2014-08-08 21:55:39]

Now looks like it's failing to build asan rt for iOS

FAILED:
/work/chromium/src/tools/clang/scripts/../../../third_party/llvm/../llvm-bootstrap-install/bin/clang++
  -DASA
N_HAS_EXCEPTIONS=1 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -stdlib=libc++ -nost
dinc++
-I/work/chromium/src/tools/clang/scripts/../../../third_party/llvm/projects/libcxx/include
-isysroot /Applicati
ons/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-fPIC -fvisibility-inlines-hi
dden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers
-pedantic -Wno-long-long -Wcovered-sw
itch-default -Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -Wall -std=c++11
-O3  -arch x86_64 -arch i386 -isysroot

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-m
in=10.5 -Iprojects/compiler-rt/lib/asan
-I/work/chromium/src/third_party/llvm/projects/compiler-rt/lib/asan -Iinclude
-I/work/chromium/src/third_party/llvm/include
-I/work/chromium/src/third_party/llvm/projects/compiler-rt/lib/asan/..
  -UNDEBUG  -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer
-funwind-tables -fno-stack-protector -fvisibility=
hidden -fno-function-sections -O3 -gline-tables-only -Wno-gnu
-Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtua
l-dtor -fno-rtti -mios-simulator-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhone
Simulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -MMD -MT
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.ioss
im.dir/asan_activation.cc.o -MF
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_activation.cc.o.d
-o p
rojects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_activation.cc.o
-c /work/chromium/src/third_party/llvm/
projects/compiler-rt/lib/asan/asan_activation.cc
clang-3.5: error: invalid argument '-mmacosx-version-min=10.5' not allowed with
'-mios-simulator-version-min=7.0'

[hans, 2014-08-09 00:05:20]

Notes to self:

$ MACOSX_DEPLOYMENT_TARGET=10.5 cmake -GNinja -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_THREADS=OFF
-DCMAKE_C_COMPILER=/work/chromium/src/third_party/llvm-bootstrap-install/bin/clang
-DCMAKE_CXX_COMPILER=/work/chromium/src/third_party/llvm-bootstrap-install/bin/clang++
'-DCMAKE_C_FLAGS=-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk'
'-DCMAKE_CXX_FLAGS=-stdlib=libc++ -nostdinc++
-I/work/chromium/src/third_party/llvm/projects/libcxx/include -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk'
'-DCMAKE_EXE_LINKER_FLAGS=-stdlib=libc++
-L/work/chromium/src/third_party/llvm-build/Release+Asserts/libcxxbuild' ..

$ MACOSX_DEPLOYMENT_TARGET=10.5 ninja
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_allocator2.cc.o

[1/1] Building CXX object
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_allocator2.cc.o
FAILED: /work/chromium/src/third_party/llvm-bootstrap-install/bin/clang++  
-DASAN_HAS_EXCEPTIONS=1 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS -stdlib=libc++ -nostdinc++
-I/work/chromium/src/third_party/llvm/projects/libcxx/include -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -Wall -std=c++11 -O3  -arch
x86_64 -arch i386 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.5 -Iprojects/compiler-rt/lib/asan
-I../projects/compiler-rt/lib/asan -Iinclude -I../include
-I../projects/compiler-rt/lib/asan/..    -UNDEBUG  -fPIC -fno-builtin
-fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector
-fvisibility=hidden -fno-function-sections -O3 -gline-tables-only -Wno-gnu
-Wno-variadic-macros -Wno-c99-extensions -Wno-non-virtual-dtor -fno-rtti
-mios-simulator-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
-MMD -MT
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_allocator2.cc.o
-MF
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_allocator2.cc.o.d
-o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_allocator2.cc.o
-c ../projects/compiler-rt/lib/asan/asan_allocator2.cc
clang-3.5: error: invalid argument '-mmacosx-version-min=10.5' not allowed with
'-mios-simulator-version-min=7.0'
clang-3.5: error: invalid argument '-mmacosx-version-min=10.5' not allowed with
'-mios-simulator-version-min=7.0'
ninja: build stopped: subcommand failed.

[hans, 2014-08-11 21:42:00]

More notes. I think I've fixed the ASan runtime issue:

The compiler-rt cmakelists.txt sets the -mmacosx-version-min and
-mios-simulator-version-min flags manually, if MACOSX_DEPLOYMENT_TARGET is set
in the environment, CMake will add that to the compile flags too. We can fix by
setting CMAKE_OSX_DEPLOYMENT_TARGET to "".


Now for the problems building libc++ and libc++abi. To reproduce, in a vanilla
llvm checkout:

Configure:

$ MACOSX_DEPLOYMENT_TARGET=10.6 cmake -GNinja -DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_THREADS=OFF
-DCMAKE_C_COMPILER=/work/chromium/src/third_party/llvm-bootstrap-install/bin/clang
-DCMAKE_CXX_COMPILER=/work/chromium/src/third_party/llvm-bootstrap-install/bin/clang++
'-DCMAKE_C_FLAGS=-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk'
'-DCMAKE_CXX_FLAGS=-stdlib=libc++ -nostdinc++
-I/work/chromium/src/third_party/llvm/projects/libcxx/include -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk'
'-DCMAKE_EXE_LINKER_FLAGS=-stdlib=libc++
-L/work/chromium/src/third_party/llvm-build/Release+Asserts/libcxxbuild' ..

Build:

$ ninja lib/libc++abi.1.0.dylib

FAILED: : && /work/chromium/src/third_party/llvm-bootstrap-install/bin/clang++  
-nostdinc++ -I/work/chromium/src/third_party/llvm/projects/libcxx/include
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -nostdinc++ -std=c++0x
-Werror=return-type -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wno-long-long -Wno-error -pedantic -D_DEBUG -UNDEBUG -O3  -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-mmacosx-version-min=10.6 -dynamiclib -Wl,-headerpad_max_install_names
-nodefaultlibs -compatibility_version 1 -current_version  -install_name
/usr/lib/libc++abi.1.dylib /usr/lib/libSystem.B.dylib -o lib/libc++abi.1.0.dylib
-install_name @rpath/libc++abi.1.dylib
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/abort_message.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_aux_runtime.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_default_handlers.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_demangle.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_exception.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_exception_storage.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_guard.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_handlers.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_new_delete.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_personality.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_unexpected.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_vector.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/cxa_virtual.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/exception.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/private_typeinfo.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/stdexcept.cpp.o
projects/libcxxabi/src/CMakeFiles/cxxabi.dir/typeinfo.cpp.o  -lc -lpthread
-Wl,-rpath,@executable_path/../lib && :
clang-3.5: error: no such file or directory: '/usr/lib/libc++abi.1.dylib'

[hans, 2014-08-11 21:46:06]

On 2014/08/11 21:42:00, hans wrote:
> clang-3.5: error: no such file or directory: '/usr/lib/libc++abi.1.dylib'

Ha! Fixed in projects/libcxxabi/src/CMakeLists.txt

${LIBCXXABI_VERSION} is never defined. Substitute by 1.

[hans, 2014-08-11 21:49:24]

And for libc++:

$ ninja lib/libc++.1.0.dylib

diff --git a/lib/CMakeLists.txt b/lib/CMakeLists.txt
index a29b6cc..d56ade4 100644
--- a/lib/CMakeLists.txt
+++ b/lib/CMakeLists.txt
@@ -54,7 +54,7 @@ if ( APPLE )
     list(APPEND compile_flags "-U__STRICT_ANSI__")
     list(APPEND link_flags
       "-compatibility_version 1"
-      "-current_version ${LIBCXX_VERSION}"
+      "-current_version 1"
       "-install_name /usr/lib/libc++.1.dylib"
       "-Wl,-reexport_library,/usr/lib/libc++abi.dylib"
      
"-Wl,-unexported_symbols_list,${CMAKE_CURRENT_SOURCE_DIR}/libc++unexp.exp"
@@ -84,6 +84,7 @@ if ( APPLE )
   endif()
 endif()

+string(REPLACE ";" " " compile_flags "${compile_flags}")
 string(REPLACE ";" " " link_flags "${link_flags}")

[hans, 2014-08-11 21:55:14]

Next up:

FAILED: : &&
/work/chromium/src/tools/clang/scripts/../../../third_party/llvm/../llvm-bootstrap-install/bin/clang++
  -nostdinc++
-I/work/chromium/src/tools/clang/scripts/../../../third_party/llvm/projects/libcxx/include
-isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default
-Wnon-virtual-dtor -std=c++11 -fcolor-diagnostics -nostdinc++ -std=c++0x
-Werror=return-type -Wall -W -Wno-unused-parameter -Wwrite-strings
-Wno-long-long -Wno-error -pedantic -D_DEBUG -UNDEBUG -O3  -arch x86_64 -arch
i386 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk
-dynamiclib -Wl,-headerpad_max_install_names -stdlib=libc++
-L/work/chromium/src/third_party/llvm-build/Release+Asserts/libcxxbuild  
-Wl,-ios_simulator_version_min,7.0.0 -mios-simulator-version-min=7.0 -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk
-o lib/clang/3.5.0/lib/darwin/libclang_rt.asan_iossim_dynamic.dylib
-install_name
/work/chromium/src/third_party/llvm-build/Release+Asserts/lib/clang/3.5.0/lib/darwin/libclang_rt.asan_iossim_dynamic.dylib
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_allocator2.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_activation.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_debugging.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_fake_stack.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_globals.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_interceptors.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_linux.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_mac.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_malloc_linux.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_malloc_mac.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_malloc_win.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_poisoning.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_posix.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_report.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_rtl.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_stack.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_stats.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_thread.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_win.cc.o
projects/compiler-rt/lib/asan/CMakeFiles/RTAsan.iossim.dir/asan_new_delete.cc.o
projects/compiler-rt/lib/interception/CMakeFiles/RTInterception.iossim.dir/interception_linux.cc.o
projects/compiler-rt/lib/interception/CMakeFiles/RTInterception.iossim.dir/interception_mac.cc.o
projects/compiler-rt/lib/interception/CMakeFiles/RTInterception.iossim.dir/interception_win.cc.o
projects/compiler-rt/lib/interception/CMakeFiles/RTInterception.iossim.dir/interception_type_test.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_allocator.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_common.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_deadlock_detector1.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_deadlock_detector2.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_flags.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_libc.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_libignore.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_linux.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_mac.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_persistent_allocator.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_platform_limits_linux.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_platform_limits_posix.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_posix.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_printf.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_procmaps_linux.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_procmaps_mac.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_stackdepot.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_stacktrace.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_suppressions.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_symbolizer.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_symbolizer_libbacktrace.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_symbolizer_win.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_tls_get_addr.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_thread_registry.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_win.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_common_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_coverage_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_coverage_mapping_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_linux_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_posix_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_stacktrace_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_stoptheworld_linux_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_symbolizer_libcdep.cc.o
projects/compiler-rt/lib/sanitizer_common/CMakeFiles/RTSanitizerCommon.iossim.dir/sanitizer_symbolizer_posix_libcdep.cc.o
projects/compiler-rt/lib/lsan/CMakeFiles/RTLSanCommon.iossim.dir/lsan_common.cc.o
projects/compiler-rt/lib/lsan/CMakeFiles/RTLSanCommon.iossim.dir/lsan_common_linux.cc.o
  && :
clang-3.5: warning: argument unused during compilation: '-nostdinc++'
clang-3.5: warning: argument unused during compilation: '-nostdinc++'
ld: building for iOS Simulator, but linking against dylib built for MacOSX file
'/work/chromium/src/third_party/llvm-build/Release+Asserts/libcxxbuild/libc++.dylib'
for architecture x86_64
clang-3.5: error: linker command failed with exit code 1 (use -v to see
invocation)
ninja: build stopped: subcommand failed.

[hans, 2014-08-13 02:43:45]

Progress. This can build Mac and Linux packages. Comparing the tgz's with the
old ones looks good. The build works on Linux (including ASan) and Mac.

The Android build seems broken, but might be for unrelated reasons. Didn't try
Mac ASan yet.

Nico: while this isn't the final version, if you'd like to take a look, it might
make sense now.

[Nico, 2014-08-13 16:24:41]

On 2014/08/13 02:43:45, hans wrote:
> Progress. This can build Mac and Linux packages. Comparing the tgz's with the
> old ones looks good. The build works on Linux (including ASan) and Mac.
> 
> The Android build seems broken, but might be for unrelated reasons. Didn't try
> Mac ASan yet.
> 
> Nico: while this isn't the final version, if you'd like to take a look, it
might
> make sense now.

(+273 lines, -172 lines)

:-/

[Nico, 2014-08-13 16:33:07]

looks ok I guess, but I don't know cmake well. (I did check that this still
enables assertions.) Maybe one of the compiler-rt cmake experts can take a look
once this is ready too :-)

How does binary size compare to the make-built clang? Can you do a (goma-less)
local build of a smallish target (say, skia) with the autoconf clang and the
cmake clang and check that build times are roughly identical?

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
File tools/clang/scripts/update.sh (right):

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:278: CC=${CC:-gcc}
I think it's better to make this default to cc, not gcc ('cause "gcc" is really
clang on os x, etc). gyp uses cc.

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:412: ninja
Hm, I think clang (!) reads MACOSX_DEPLOYMENT_TARGET from the env, are you sure
this doesn't need to be set at ninja time? Or do the ninja files that cmake
writes convert MACOSX_DEPLOYMENT_TARGET to a -mmacosx-version-min flags? Did you
check the output of `otool -l bin/clang | grep -A 5 LC_VERSION_MIN_MACOSX`?

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:440: # Darwin doesn't support cp --parents, so
pipe through tar instead.
Is this going to include .svn folders?

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:448: fi
Do we want to strip compiler-rt?

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:503: -DCMAKE_CXX_FLAGS="${CXXFLAGS}" \
Most of these flags are the same every time, maybe we can put most of them in a
variable, or have a run_cmake function, or…?

[hans, 2014-08-13 20:31:03]

I'm currently building binaries based on this version of the script, that I plan
to push to take to goma and our tryservers.

On 2014/08/13 16:33:07, Nico (very away) wrote:
> looks ok I guess, but I don't know cmake well. (I did check that this still
> enables assertions.) Maybe one of the compiler-rt cmake experts can take a
look
> once this is ready too :-)

I'm adding samsonov and eugenis for extra expertise.

> How does binary size compare to the make-built clang?

I've only done this on Linux, because building on my Mac Mini takes eons:

Autoconf:

$ ls -l third_party/llvm-build/Release+Asserts/bin/clang
-rwxr-x--- 1 hwennborg eng 51288888 Aug 13 11:07
third_party/llvm-build/Release+Asserts/bin/clang
$ ls -l /tmp/clang-215468.tgz.autoconf
-rw-r----- 1 hwennborg eng 24123352 Aug 13 11:14 /tmp/clang-215468.tgz.autoconf

CMake:

$ ls -l third_party/llvm-build/Release+Asserts/bin/clang-3.6
-rwxr-x--- 1 hwennborg eng 51223328 Aug 13 12:08
third_party/llvm-build/Release+Asserts/bin/clang-3.6
$ ls -l /tmp/clang-215468.tgz.cmake
-rw-r----- 1 hwennborg eng 24684171 Aug 13 12:12 /tmp/clang-215468.tgz.cmake

Diffing the contents of the tarballs shows that we have a few more .a files,
explaining the size increase:

--- autoconf.txt        2014-08-13 13:22:09.751073362 -0700
+++ cmake.txt   2014-08-13 13:22:17.895228116 -0700
@@ -28,7 +28,6 @@
 lib/clang/3.6.0/include/lzcntintrin.h
 lib/clang/3.6.0/include/__wmmintrin_pclmul.h
 lib/clang/3.6.0/include/Intrin.h
-lib/clang/3.6.0/include/.dir
 lib/clang/3.6.0/include/ia32intrin.h
 lib/clang/3.6.0/include/fmaintrin.h
 lib/clang/3.6.0/include/nmmintrin.h
@@ -68,6 +67,8 @@
 lib/clang/3.6.0/include/tmmintrin.h
 lib/clang/3.6.0/include/fma4intrin.h
 lib/clang/3.6.0/include/stdbool.h
+lib/clang/3.6.0/msan_blacklist.txt
+lib/clang/3.6.0/asan_blacklist.txt
 lib/clang/3.6.0/lib/
 lib/clang/3.6.0/lib/linux/
 lib/clang/3.6.0/lib/linux/libclang_rt.profile-x86_64.a
@@ -78,12 +79,20 @@
 lib/clang/3.6.0/lib/linux/libclang_rt.asan-i386.a
 lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
 lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-i386.a
+lib/clang/3.6.0/lib/linux/libclang_rt.profile-pic-i386.a
 lib/clang/3.6.0/lib/linux/libclang_rt.san-x86_64.a
 lib/clang/3.6.0/lib/linux/libclang_rt.asan-arm-android.so
 lib/clang/3.6.0/lib/linux/libclang_rt.asan-x86_64.a
 lib/clang/3.6.0/lib/linux/libclang_rt.tsan-x86_64.a
+lib/clang/3.6.0/lib/linux/libclang_rt.asan-x86_64.a.syms
+lib/clang/3.6.0/lib/linux/libclang_rt.ubsan_cxx-x86_64.a.syms
+lib/clang/3.6.0/lib/linux/libclang_rt.msan-x86_64.a.syms
 lib/clang/3.6.0/lib/linux/libclang_rt.ubsan_cxx-i386.a
+lib/clang/3.6.0/lib/linux/libclang_rt.tsan-x86_64.a.syms
 lib/clang/3.6.0/lib/linux/libclang_rt.ubsan-x86_64.a
+lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-x86_64.a.syms
+lib/clang/3.6.0/lib/linux/libclang_rt.profile-pic-x86_64.a
+lib/clang/3.6.0/lib/linux/libclang_rt.ubsan-x86_64.a.syms
 lib/clang/3.6.0/lib/linux/libclang_rt.ubsan_cxx-x86_64.a
 lib/libstdc++.so.6
 lib/libBlinkGCPlugin_10.so

> Can you do a (goma-less)
> local build of a smallish target (say, skia) with the autoconf clang and the
> cmake clang and check that build times are roughly identical?

Again, on Linux:

Autoconf:

$ time ninja -C out/Release net_unittests
ninja: Entering directory `out/Release'
[2448/2448] LINK net_unittests

real    2m10.378s
user    60m7.322s
sys     2m21.839s

CMake:

$ time ninja -C out/Release net_unittests
ninja: Entering directory `out/Release'
[2441/2441] LINK net_unittests

real    2m8.133s
user    60m42.948s
sys     2m26.794s

(It seems I didn't hit the exact same Chromium revision, but it should be close
enough.)

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
File tools/clang/scripts/update.sh (right):

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:278: CC=${CC:-gcc}
On 2014/08/13 16:33:07, Nico (very away) wrote:
> I think it's better to make this default to cc, not gcc ('cause "gcc" is
really
> clang on os x, etc). gyp uses cc.

Done.

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:412: ninja
On 2014/08/13 16:33:07, Nico (very away) wrote:
> Hm, I think clang (!) reads MACOSX_DEPLOYMENT_TARGET from the env, are you
sure
> this doesn't need to be set at ninja time? Or do the ninja files that cmake
> writes convert MACOSX_DEPLOYMENT_TARGET to a -mmacosx-version-min flags?

Yes, CMake will add -mmacosx-version-min if MACOSX_DEPLOYMENT_TARGET is set.

> Did you
> check the output of `otool -l bin/clang | grep -A 5 LC_VERSION_MIN_MACOSX`?

      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.6
      sdk 10.9
Load command 10
        cmd LC_UNIXTHREAD

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:440: # Darwin doesn't support cp --parents, so
pipe through tar instead.
On 2014/08/13 16:33:07, Nico (very away) wrote:
> Is this going to include .svn folders?

It would if there were any, but we never copy from any source dirs. I double
checked that the tarballs are clean from .svn dirs too.

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:448: fi
On 2014/08/13 16:33:07, Nico (very away) wrote:
> Do we want to strip compiler-rt?

We already do it for Linux in package.sh. I've added it there for Darwin too.

https://codereview.chromium.org/453513004/diff/120001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:503: -DCMAKE_CXX_FLAGS="${CXXFLAGS}" \
On 2014/08/13 16:33:07, Nico (very away) wrote:
> Most of these flags are the same every time, maybe we can put most of them in
a
> variable, or have a run_cmake function, or…?

Yeah :/ When we move this to the .py script one day, I think we should use a
utility function, but for this bash version, I prefer to spell it out, as the
values of many of the referenced variables do change e.g. between the bootstrap
and regular builds.

[Nico, 2014-08-13 20:47:17]

What's up with the .syms files?


On Wed, Aug 13, 2014 at 1:31 PM, <hans@chromium.org> wrote:

> I'm currently building binaries based on this version of the script, that
> I plan
> to push to take to goma and our tryservers.
>
>
> On 2014/08/13 16:33:07, Nico (very away) wrote:
>
>> looks ok I guess, but I don't know cmake well. (I did check that this
>> still
>> enables assertions.) Maybe one of the compiler-rt cmake experts can take a
>>
> look
>
>> once this is ready too :-)
>>
>
> I'm adding samsonov and eugenis for extra expertise.
>
>
>  How does binary size compare to the make-built clang?
>>
>
> I've only done this on Linux, because building on my Mac Mini takes eons:
>
> Autoconf:
>
> $ ls -l third_party/llvm-build/Release+Asserts/bin/clang
> -rwxr-x--- 1 hwennborg eng 51288888 Aug 13 11:07
> third_party/llvm-build/Release+Asserts/bin/clang
> $ ls -l /tmp/clang-215468.tgz.autoconf
> -rw-r----- 1 hwennborg eng 24123352 Aug 13 11:14
> /tmp/clang-215468.tgz.autoconf
>
> CMake:
>
> $ ls -l third_party/llvm-build/Release+Asserts/bin/clang-3.6
> -rwxr-x--- 1 hwennborg eng 51223328 Aug 13 12:08
> third_party/llvm-build/Release+Asserts/bin/clang-3.6
> $ ls -l /tmp/clang-215468.tgz.cmake
> -rw-r----- 1 hwennborg eng 24684171 Aug 13 12:12
> /tmp/clang-215468.tgz.cmake
>
> Diffing the contents of the tarballs shows that we have a few more .a
> files,
> explaining the size increase:
>
> --- autoconf.txt        2014-08-13 13:22:09.751073362 -0700
> +++ cmake.txt   2014-08-13 13:22:17.895228116 -0700
> @@ -28,7 +28,6 @@
>  lib/clang/3.6.0/include/lzcntintrin.h
>  lib/clang/3.6.0/include/__wmmintrin_pclmul.h
>  lib/clang/3.6.0/include/Intrin.h
> -lib/clang/3.6.0/include/.dir
>  lib/clang/3.6.0/include/ia32intrin.h
>  lib/clang/3.6.0/include/fmaintrin.h
>  lib/clang/3.6.0/include/nmmintrin.h
> @@ -68,6 +67,8 @@
>  lib/clang/3.6.0/include/tmmintrin.h
>  lib/clang/3.6.0/include/fma4intrin.h
>  lib/clang/3.6.0/include/stdbool.h
> +lib/clang/3.6.0/msan_blacklist.txt
> +lib/clang/3.6.0/asan_blacklist.txt
>  lib/clang/3.6.0/lib/
>  lib/clang/3.6.0/lib/linux/
>  lib/clang/3.6.0/lib/linux/libclang_rt.profile-x86_64.a
> @@ -78,12 +79,20 @@
>  lib/clang/3.6.0/lib/linux/libclang_rt.asan-i386.a
>  lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-x86_64.a
>  lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-i386.a
> +lib/clang/3.6.0/lib/linux/libclang_rt.profile-pic-i386.a
>  lib/clang/3.6.0/lib/linux/libclang_rt.san-x86_64.a
>  lib/clang/3.6.0/lib/linux/libclang_rt.asan-arm-android.so
>  lib/clang/3.6.0/lib/linux/libclang_rt.asan-x86_64.a
>  lib/clang/3.6.0/lib/linux/libclang_rt.tsan-x86_64.a
> +lib/clang/3.6.0/lib/linux/libclang_rt.asan-x86_64.a.syms
> +lib/clang/3.6.0/lib/linux/libclang_rt.ubsan_cxx-x86_64.a.syms
> +lib/clang/3.6.0/lib/linux/libclang_rt.msan-x86_64.a.syms
>  lib/clang/3.6.0/lib/linux/libclang_rt.ubsan_cxx-i386.a
> +lib/clang/3.6.0/lib/linux/libclang_rt.tsan-x86_64.a.syms
>  lib/clang/3.6.0/lib/linux/libclang_rt.ubsan-x86_64.a
> +lib/clang/3.6.0/lib/linux/libclang_rt.asan_cxx-x86_64.a.syms
> +lib/clang/3.6.0/lib/linux/libclang_rt.profile-pic-x86_64.a
> +lib/clang/3.6.0/lib/linux/libclang_rt.ubsan-x86_64.a.syms
>  lib/clang/3.6.0/lib/linux/libclang_rt.ubsan_cxx-x86_64.a
>  lib/libstdc++.so.6
>  lib/libBlinkGCPlugin_10.so
>
>
>  Can you do a (goma-less)
>> local build of a smallish target (say, skia) with the autoconf clang and
>> the
>> cmake clang and check that build times are roughly identical?
>>
>
> Again, on Linux:
>
> Autoconf:
>
> $ time ninja -C out/Release net_unittests
> ninja: Entering directory `out/Release'
> [2448/2448] LINK net_unittests
>
> real    2m10.378s
> user    60m7.322s
> sys     2m21.839s
>
> CMake:
>
> $ time ninja -C out/Release net_unittests
> ninja: Entering directory `out/Release'
> [2441/2441] LINK net_unittests
>
> real    2m8.133s
> user    60m42.948s
> sys     2m26.794s
>
> (It seems I didn't hit the exact same Chromium revision, but it should be
> close
> enough.)
>
>
>
>
> https://codereview.chromium.org/453513004/diff/120001/
> tools/clang/scripts/update.sh
> File tools/clang/scripts/update.sh (right):
>
> https://codereview.chromium.org/453513004/diff/120001/
> tools/clang/scripts/update.sh#newcode278
> tools/clang/scripts/update.sh:278: CC=${CC:-gcc}
> On 2014/08/13 16:33:07, Nico (very away) wrote:
>
>> I think it's better to make this default to cc, not gcc ('cause "gcc"
>>
> is really
>
>> clang on os x, etc). gyp uses cc.
>>
>
> Done.
>
>
> https://codereview.chromium.org/453513004/diff/120001/
> tools/clang/scripts/update.sh#newcode412
> tools/clang/scripts/update.sh:412: ninja
> On 2014/08/13 16:33:07, Nico (very away) wrote:
>
>> Hm, I think clang (!) reads MACOSX_DEPLOYMENT_TARGET from the env, are
>>
> you sure
>
>> this doesn't need to be set at ninja time? Or do the ninja files that
>>
> cmake
>
>> writes convert MACOSX_DEPLOYMENT_TARGET to a -mmacosx-version-min
>>
> flags?
>
> Yes, CMake will add -mmacosx-version-min if MACOSX_DEPLOYMENT_TARGET is
> set.
>
>
>  Did you
>> check the output of `otool -l bin/clang | grep -A 5
>>
> LC_VERSION_MIN_MACOSX`?
>
>       cmd LC_VERSION_MIN_MACOSX
>   cmdsize 16
>   version 10.6
>       sdk 10.9
> Load command 10
>         cmd LC_UNIXTHREAD
>
>
> https://codereview.chromium.org/453513004/diff/120001/
> tools/clang/scripts/update.sh#newcode440
> tools/clang/scripts/update.sh:440: # Darwin doesn't support cp
> --parents, so pipe through tar instead.
> On 2014/08/13 16:33:07, Nico (very away) wrote:
>
>> Is this going to include .svn folders?
>>
>
> It would if there were any, but we never copy from any source dirs. I
> double checked that the tarballs are clean from .svn dirs too.
>
>
> https://codereview.chromium.org/453513004/diff/120001/
> tools/clang/scripts/update.sh#newcode448
> tools/clang/scripts/update.sh:448: fi
> On 2014/08/13 16:33:07, Nico (very away) wrote:
>
>> Do we want to strip compiler-rt?
>>
>
> We already do it for Linux in package.sh. I've added it there for Darwin
> too.
>
>
> https://codereview.chromium.org/453513004/diff/120001/
> tools/clang/scripts/update.sh#newcode503
> tools/clang/scripts/update.sh:503: -DCMAKE_CXX_FLAGS="${CXXFLAGS}" \
> On 2014/08/13 16:33:07, Nico (very away) wrote:
>
>> Most of these flags are the same every time, maybe we can put most of
>>
> them in a
>
>> variable, or have a run_cmake function, or...?
>>
>
> Yeah :/ When we move this to the .py script one day, I think we should
> use a utility function, but for this bash version, I prefer to spell it
> out, as the values of many of the referenced variables do change e.g.
> between the bootstrap and regular builds.
>
> https://codereview.chromium.org/453513004/
>

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-08-13 20:55:27]

On 2014/08/13 20:47:17, Nico (very away) wrote:
> What's up with the .syms files?

They're created in the CMake build but not the autoconf one. I'm not sure why.
We probably don't need to include them.

[chromium-reviews, 2014-08-14 01:02:44]

On Wed, Aug 13, 2014 at 1:55 PM, <hans@chromium.org> wrote:

> On 2014/08/13 20:47:17, Nico (very away) wrote:
>
>> What's up with the .syms files?
>>
>
> They're created in the CMake build but not the autoconf one. I'm not sure
> why.
> We probably don't need to include them.
>

Building .syms files were indeed not implemented in autoconf build. They
are optional, but generally they will do no harm, and can improve things.
If you build sanitized executable, and there is a .syms file, Clang driver
will add a linker flag "--dynamic_list=/path/to/syms/file", otherwise it
would
add "--export-dynamic", and as a result dynamic symbol table in the
executable might be huge, visibly increasing the binary size. It was
important for google3,
I don't know how important it is for Chrome.


>
> https://codereview.chromium.org/453513004/
>



-- 
Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-08-14 01:35:23]

Sounds like having the .syms file might be a good thing.

Pushed new Mac and Linux binaries built at Chromium r289397. Just waiting for
goma now.

[Nico, 2014-08-14 17:30:37]

mostly lgtm

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
File tools/clang/scripts/update.sh (right):

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:36: $(grep 'set( LIBRARYNAME'
"$THIS_DIR"/../blink_gc_plugin/CMakeLists.txt \
(do cmake files have spaces after set(s, usually)

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:221: # Check that cmake and ninja are available.
Maybe

if ! which cmake > /dev/null; then
  echo "Cmake needed to build clang, please install"
fi

and the same for ninja?

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:236: # We have changed the compiler_rt, so nuke
the old one.
Why is this needed?

[Nico, 2014-08-14 17:32:56]

(cc'ing a few folks who might care that the clang plugins are moving from make
to cmake)

[hans, 2014-08-14 19:39:40]

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
File tools/clang/scripts/update.sh (right):

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:36: $(grep 'set( LIBRARYNAME'
"$THIS_DIR"/../blink_gc_plugin/CMakeLists.txt \
On 2014/08/14 17:30:37, Nico (very away) wrote:
> (do cmake files have spaces after set(s, usually)

There is precedence in some LLVM files for this, but I think most code doesn't
have it.

I'll tweak the grep/cut line instead.

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:221: # Check that cmake and ninja are available.
On 2014/08/14 17:30:37, Nico (very away) wrote:
> Maybe
> 
> if ! which cmake > /dev/null; then
>   echo "Cmake needed to build clang, please install"
> fi
> 
> and the same for ninja?

Done.

https://codereview.chromium.org/453513004/diff/160001/tools/clang/scripts/upd...
tools/clang/scripts/update.sh:236: # We have changed the compiler_rt, so nuke
the old one.
On 2014/08/14 17:30:36, Nico (very away) wrote:
> Why is this needed?

If there is a stale copy checked out in-tree, it will get built, and we don't
want that.

My comment here was pretty bad though :) I've updated it.

[Nico, 2014-08-14 19:44:44]

lgtm, gulp (with "(WIP)" removed from the description)

[hans, 2014-08-14 19:57:03]

On 2014/08/14 19:44:44, Nico (very away) wrote:
> lgtm, gulp (with "(WIP)" removed from the description)

Thanks!

For those following along: this will still take a while to land (need Android
fix, warning cleanup, ..., and then lots of try jobs), and the Clang revision
isn't fixed, this was just the first one that had my upstream cmake changes.

[hans, 2014-08-15 22:58:46]

I think the tryjobs look pretty good.

- mac_asan_64 bot seems broken; it builds and runs locally for me.

- linux_asan and linux_chromeos_asan are erroring on memory leaks. I didn't know
we run lsan as part of asan builds. Is this new? Maybe samsonov knows?

[chromium-reviews, 2014-08-18 01:04:49]

+earthdok

On Fri, Aug 15, 2014 at 3:58 PM, <hans@chromium.org> wrote:

> I think the tryjobs look pretty good.
>
> - mac_asan_64 bot seems broken; it builds and runs locally for me.
>
> - linux_asan and linux_chromeos_asan are erroring on memory leaks. I
> didn't know
> we run lsan as part of asan builds. Is this new? Maybe samsonov knows?
>

Hm.. IIRC we recently flipped the default and enabled leak checking in ASan
by default. It's controlled
by the runtime flag "detect_leaks". I don't know if we have a Chromium-wide
set of default runtime options
for ASan (definition of __asan_default_options somewhere). Alex and Sergey
probably know this.


>
> https://codereview.chromium.org/453513004/
>



-- 
Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Alexander Potapenko, 2014-08-18 15:56:11]

We're setting detect_leaks=0 by default in base/debug/sanitizer_options.cc
Bots running non-browser tests do enable leak detection (look for "Additional
test environment:" in the test stdio), and the reported leaks are known ones.
I suppose the path to suppressions file
(suppressions=src/tools/lsan/suppressions.txt) is incorrect.

[hans, 2014-08-18 17:14:14]

On 2014/08/18 15:56:11, glider (OOO till Aug 16) wrote:
> We're setting detect_leaks=0 by default in base/debug/sanitizer_options.cc
> Bots running non-browser tests do enable leak detection (look for "Additional
> test environment:" in the test stdio), and the reported leaks are known ones.
> I suppose the path to suppressions file
> (suppressions=src/tools/lsan/suppressions.txt) is incorrect.

Thanks for the info!

I wonder what's changed:
lang roll:
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_asan/buil...
Whitespace change:
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_asan/buil...

They both set suppressions=src/tools/lsan/suppressions.txt, but in the Clang
roll we fail to suppress the failure from base_unittests:MemoryLeak :/

[hans, 2014-08-18 17:55:08]

I can reproduce the lsan problem locally:

export GYP_DEFINES="clang=1 asan=1 lsan=1 use_allocator=none fastbuild=0
component=static_library"
ninja -C out/Release base_unittests
ASAN_SYMBOLIZER_PATH=/work/chromium/src/third_party/llvm-build/Release+Asserts/bin/llvm-symbolizer
ASAN_OPTIONS="detect_leaks=1 symbolize=1"
LSAN_OPTIONS="suppressions=tools/lsan/suppressions.txt"
out/Release/base_unittests --gtest_filter="*MemoryLeak*"

The test passes on trunk, but fails with my roll.

I think the problem is the suppressions file doesn't get parsed if it's in
LSAN_OPTIONS. If I move it to ASAN_OPTIONS, it works.

I noticed that this is also the case with the upstream test in
test/lsan/TestCases/suppressions_file.cc. If I remove the suppressions file from
ASAN_OPTIONS so that it's only set in LSAN_OPTIONS, the test fails on trunk.

Alexey, you committed some refactorings to the suppressions parsing code in
compiler-rt that are included in this roll. Can you take a look?

[hans, 2014-08-18 18:36:16]

On 2014/08/18 17:55:08, hans wrote:
> I can reproduce the lsan problem locally:
> 
> export GYP_DEFINES="clang=1 asan=1 lsan=1 use_allocator=none fastbuild=0
> component=static_library"
> ninja -C out/Release base_unittests
>
ASAN_SYMBOLIZER_PATH=/work/chromium/src/third_party/llvm-build/Release+Asserts/bin/llvm-symbolizer
> ASAN_OPTIONS="detect_leaks=1 symbolize=1"
> LSAN_OPTIONS="suppressions=tools/lsan/suppressions.txt"
> out/Release/base_unittests --gtest_filter="*MemoryLeak*"
> 
> The test passes on trunk, but fails with my roll.
> 
> I think the problem is the suppressions file doesn't get parsed if it's in
> LSAN_OPTIONS. If I move it to ASAN_OPTIONS, it works.
> 
> I noticed that this is also the case with the upstream test in
> test/lsan/TestCases/suppressions_file.cc. If I remove the suppressions file
from
> ASAN_OPTIONS so that it's only set in LSAN_OPTIONS, the test fails on trunk.
> 
> Alexey, you committed some refactorings to the suppressions parsing code in
> compiler-rt that are included in this roll. Can you take a look?

It looks like r214343 is the culprit.

[chromium-reviews, 2014-08-18 23:49:57]

Right, thanks for pointing it out. I've submitted r215949, which should fix
things - now suppressions file provided in LSAN_OPTIONS will be used even
if we run the binary under ASan+LSan.


On Mon, Aug 18, 2014 at 11:36 AM, <hans@chromium.org> wrote:

> On 2014/08/18 17:55:08, hans wrote:
>
>> I can reproduce the lsan problem locally:
>>
>
>  export GYP_DEFINES="clang=1 asan=1 lsan=1 use_allocator=none fastbuild=0
>> component=static_library"
>> ninja -C out/Release base_unittests
>>
>
> ASAN_SYMBOLIZER_PATH=/work/chromium/src/third_party/llvm-
> build/Release+Asserts/bin/llvm-symbolizer
>
>> ASAN_OPTIONS="detect_leaks=1 symbolize=1"
>> LSAN_OPTIONS="suppressions=tools/lsan/suppressions.txt"
>> out/Release/base_unittests --gtest_filter="*MemoryLeak*"
>>
>
>  The test passes on trunk, but fails with my roll.
>>
>
>  I think the problem is the suppressions file doesn't get parsed if it's in
>> LSAN_OPTIONS. If I move it to ASAN_OPTIONS, it works.
>>
>
>  I noticed that this is also the case with the upstream test in
>> test/lsan/TestCases/suppressions_file.cc. If I remove the suppressions
>> file
>>
> from
>
>> ASAN_OPTIONS so that it's only set in LSAN_OPTIONS, the test fails on
>> trunk.
>>
>
>  Alexey, you committed some refactorings to the suppressions parsing code
>> in
>> compiler-rt that are included in this roll. Can you take a look?
>>
>
> It looks like r214343 is the culprit.
>
> https://codereview.chromium.org/453513004/
>



-- 
Alexey Samsonov, Mountain View, CA

To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[hans, 2014-08-19 02:33:16]

On 2014/08/18 23:49:57, chromium-reviews wrote:
> Right, thanks for pointing it out. I've submitted r215949, which should fix
> things - now suppressions file provided in LSAN_OPTIONS will be used even
> if we run the binary under ASan+LSan.

Thanks for fixing! I've pushed Clang based on that revision and will run some
tryjobs.

[hans, 2014-08-19 23:33:09]

Tryjobs look beautiful. Now we just need a blessed revision.

[hans, 2014-08-28 18:24:23]

The failure on ScopedPtrTest.ScopedPtrWithArray on linux_asan and
linux_chromeos_asan is new :/

[hans, 2014-09-15 21:59:23]

Tryjobs look good (whitespace change for comparison:
https://codereview.chromium.org/405473002/), I've updated the change description
and think this is ready to go.

Please take a final look.

[Nico, 2014-09-15 22:05:19]

still lgtm

(are the plugins built with today's-ish code?)

[hans, 2014-09-15 22:08:17]

On 2014/09/15 22:05:19, Nico (hiding) wrote:
> still lgtm

Thanks!

> (are the plugins built with today's-ish code?)

Yup, binaries were built at #294830 from this morning.

[hans, 2014-09-15 22:08:42]

The CQ bit was checked by hans@chromium.org

[hans, 2014-09-15 22:28:00]

The CQ bit was unchecked by hans@chromium.org

[hans, 2014-09-15 22:28:13]

The CQ bit was checked by hans@chromium.org

[commit-bot: I haz the power, 2014-09-15 22:40:02]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/453513004/380001

[commit-bot: I haz the power, 2014-09-16 00:48:23]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-16 00:48:25]

Try jobs failed on following builders:
  chromium_presubmit on tryserver.chromium.linux
(http://build.chromium.org/p/tryserver.chromium.linux/builders/chromium_presub...)

[commit-bot: I haz the power, 2014-09-16 01:01:57]

Patchset 20 (id:??) landed as
https://crrev.com/ff31c1ba254ca37f7a8b45549e1b7b1c978b3390
Cr-Commit-Position: refs/heads/master@{#294953}

[hans, 2014-09-16 01:02:03]

Committed patchset #20 (id:380001) manually as ff31c1b (presubmit successful).

[hans, 2014-09-16 01:21:24]

A revert of this CL (patchset #20 id:380001) has been created in
https://codereview.chromium.org/567443003/ by hans@chromium.org.

The reason for reverting is: Builds failing with:

../../third_party/skia/include/core/SkRect.h:280:25: error: reference cannot be
bound to dereferenced null pointer in well-defined C++ code; pointer may be
assumed to always convert to true [-Werror,-Wundefined-bool-conversion]
        SkASSERT(&a && &b);
                    ~~  ^
../../third_party/skia/include/core/SkTypes.h:96:56: note: expanded from macro
'SkASSERT'
    #define SkASSERT(cond)              SK_ALWAYSBREAK(cond)
                                                       ^
../../third_party/skia/include/core/SkPostConfig.h:173:19: note: expanded from
macro 'SK_ALWAYSBREAK'
              if (cond) break; \
                  ^

(From
http://build.chromium.org/p/chromium.linux/builders/Linux%20GN%20%28dbg%29/bu...).