Adjust GN configs to only link with Control Flow Guard for executables.
This will still support CFG compiled into Microsoft system DLLs, in all
Chromium processes (e.g. chrome.exe).
This should prevent sporadic official clang build problems in DLLs, related
to CFG. Further investigation/fixes to follow.
TEST=CFGSupportTests.MsIndirectFailure in sbox_integration_tests suite.
BUG=584575,708098
Review-Url: https://codereview.chromium.org/2813823006
Cr-Original-Commit-Position: refs/heads/master@{#464475}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 723503ec2956cc8b66e53a5ee97985ec262a599d
Previously this was guarded with use_clang on shared_library_config, but
some targets use static_config directly.
BUG=b/37232530
TEST=Build and run device. Check {C/LD}FLAGS
Review-Url: https://codereview.chromium.org/2808253003
Cr-Original-Commit-Position: refs/heads/master@{#463795}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 58a97b349697f6764d0d0304a8374da957ef2207
Increase build parity between chromecast and non-chromecast build. Also
adds more checks. Internal builds all compiled without issue.
BUG=581409, internal b/37211660
Review-Url: https://codereview.chromium.org/2810923002
Cr-Original-Commit-Position: refs/heads/master@{#463515}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: be7bac4630c397e4cb8773fc93e1c559c3bfebdb
This generalizes the fall-back to using base::debug::StackTrace to
capture stack traces in builds which lack frame pointers, allowing
native heap profiling to generate useful data, albeit with a more
significant performance penalty.
Changes made in the earlier patch for native heap profiling stack
capture under Windows are un-done in favour of the following:
1. MemoryDumpManager always allows native heap profiling[1].
2. HeapProfilerAllocationContextTracker chooses whether to use
base::debug::StackTrace or TraceStackFramePointers() based on
the value of BUILDFLAG(CAN_UNWIND_WITH_FRAME_POINTERS).
3. BUILDFLAG(CAN_UNWIND_WITH_FRAME_POINTERS) is no longer defined in
configurations which we cannot use frame pointers for unwinding[2].
[1] Though note that only certain build configs actually support
the necessary allocator shims; this will be addressed later.
[2] Frame pointers are only available in profiling & Debug builds on
some platforms, and are available but unsuitable for us to use for
stack unwinding, on others.
BUG=686208
Review-Url: https://codereview.chromium.org/2757123002
Review-Url: https://codereview.chromium.org/2757123002
Cr-Original-Commit-Position: refs/heads/master@{#463411}
Committed: 22b017b9b2
Cr-Original-Original-Commit-Position: refs/heads/master@{#460311}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 460b12442f72be8185a80cbf1ec0be6d11a27515
This change was motivated by the need to remove the
references to wheezy. I noticed that the target_sysroot_dir
argument could be generalized which avoids the extra
conditional in sysroot.gni.
BUG=697494
Review-Url: https://codereview.chromium.org/2810633004
Cr-Original-Commit-Position: refs/heads/master@{#463368}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 75cc3b096e245801afa0607dc4f8adc03566ae16
All platforms now specify whether to emit frame pointers by default, rather than
relying on default compiler options.
This CL moves the logic from config("default_stack_frames") into compiler.gni.
The former is actually the right place for the logic to live, but there exists
code that relies on whether a frame pointer is emitted by default. Right now,
that logic is being duplicated/guessed by the code in question. This CL at least
unifies the logic in a single location.
There current exists code that uses a preprocessor definition
HAVE_TRACE_STACK_FRAME_POINTERS. Despite the name, the code really wants to know
if most stacks can be unwound using stack pointers. I've renamed it to
CAN_UNWIND_WITH_FRAME_POINTERS. Arguably, any code that uses
CAN_UNWIND_WITH_FRAME_POINTERS is broken and should be removed, since it relies
on the assumption that all stacks will either have or not have frame pointers,
but that can vary TU by TU.
BUG=706116, 706654
Review-Url: https://codereview.chromium.org/2782063005
Cr-Original-Commit-Position: refs/heads/master@{#462622}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f7c8a0df4253be5271276dc7f3c1da5ce9b677c1
Building with the wheezy sysroot and is_clang=false results in errors
like this:
../../base/process/process_iterator.h:12:16: fatal error: list: No
such file or directory
#include <list>
[1] added a restriction that use_sysroot must be false when building
with is_clang=false. However, as of [2], the wheezy sysroot has been
removed, and these compilation errors are not present on the Jessie
sysroot. This CL removes the restriction added by [1].
[1] https://codereview.chromium.org/1476923005
[2] https://codereview.chromium.org/2597523003
BUG=575778
R=dpranke@chromium.org
Review-Url: https://codereview.chromium.org/2804633005
Cr-Original-Commit-Position: refs/heads/master@{#462343}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: c2c8a4d94797d67f76e061be40cfed0378eccd81
It was disabled in BUILD.gn, because there are known failures,
but recently Clang enabled it by default, so we have to opt out.
Eventually, we need to clean up these failures and reenable the
check as it's useful.
BUG=708216,708707
Review-Url: https://codereview.chromium.org/2797253002
Cr-Original-Commit-Position: refs/heads/master@{#462187}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 69faa6a6ffc1ceebf4d499618a5d17c8a1e7af67
Adding frameworks jar build from the android-7.1.1_r28 tag
in AOSP.
Bug:707823
Change-Id: Ifbe2c91aa1b495b0959b5de026bc9fd690474b12
Reviewed-on: https://chromium-review.googlesource.com/466631
Reviewed-by: John Budorick <jbudorick@chromium.org>
Reviewed-by: Selim Gurun <sgurun@chromium.org>
Commit-Queue: Michael Case <mikecase@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#461605}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a2b501b65e0987b4f2a23561a4906eb02f955a40
When doing x64 builds of Chrome with VC++ we compile some modules
(currently just libyuv) with clang, in order to get inline assembly
support. This causes problems on /analyze builds because clang-cl
doesn't understand the /analyze compiler switches. This change
disables /analyze for those files that are compiled with clang.
With this change I can do a /analyze build of libyuv without
hitting any errors, but warnings are emitted as appropriate.
R=brettw@chromium.org
BUG=427616
Review-Url: https://codereview.chromium.org/2786733005
Cr-Original-Commit-Position: refs/heads/master@{#460874}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: bb4bb0ebf2bfc2881100122e1513ee3f694744a0
Create an OWNERS file for this directory and add myself as well. This is
preparation for using a shared FreeType between Blink and PDFium, but
not actually used as a depedency to any Windows targets yet.
BUG=700926
Review-Url: https://codereview.chromium.org/2781773003
Cr-Original-Commit-Position: refs/heads/master@{#460211}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: e15f5107bfba9080481fd78ed35c69c81fc41ac3
llvm-ar is faster and is capable of handling
LLVM bitcode files without a need for a Gold plugin.
BUG=660216,607968
Review-Url: https://codereview.chromium.org/2766333002
Cr-Original-Commit-Position: refs/heads/master@{#460129}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 8968cd5170f4a22b1c508ffa3bc240b346c44b1b
When building a custom framework, the framework and the framework_dir
flags need to be added to the command-line of every linkable target
the depends directly or indirectly on it. GN propagates properly the
framework as it knows about "libs", but the -F flag added to ldflags
need to be propagated using all_dependent_configs.
BUG=704946
Review-Url: https://codereview.chromium.org/2778813002
Cr-Original-Commit-Position: refs/heads/master@{#460071}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 5376139411f2b362d24abc27425f3827697a46d4
This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.
1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster.
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.
There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)
People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.
Remove the explicit gdb_index gn arg now that this has a good default.
2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.
Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots. For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.
*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.
BUG=374952
R=piman@chromium.org, tansell@chromium.org
Review-Url: https://codereview.chromium.org/2770933009
Review-Url: https://codereview.chromium.org/2770933009 .
Cr-Original-Commit-Position: refs/heads/master@{#459824}
Committed: 7b26c51270
Cr-Original-Original-Commit-Position: refs/heads/master@{#459790}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: b9f7581b93ae8096afed29d415791803caf2e2e3
Reason for revert:
Suspicion that it cause a compile failure on https://build.chromium.org/p/chromium.linux/builders/Linux%20Builder%20%28dbg%29%2832%29/builds/65207
Original issue's description:
> linux: Improve gdb startup time for debug builds from over 4 minutes to 35s.
>
> This change contains two parts, for full-symbol (symbol_level=2, default)
> and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
> builds.
>
> 1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
> write an index that lets it load binaries much faster.
> gdb startup time for target chrome from goes from 60s to 10s and time from
> `run` in gdb to the program actually starting from 270s to 45s.
> In return, this slows down linking a bit, but for target chrome in a
> debug build, it increases link time from 37s to 42s, which is better than
> making people who want to use gdb wait several minutes every time they start
> gdb.
>
> There's some history here: We used to pass -Wl,--gdb-index long ago, and
> then removed it in https://codereview.chromium.org/335903002/, with the
> recommendation that people who want to use gdb could run build/gdb-add-index.
> But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
> that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
> not yet defaulting to component builds in debug builds, was slower. Also,
> people were on an older default Ubuntu and used an older gdb version.)
>
> People who don't use gdb should use symbol_level=1 for their builds anyhow
> (and bots do too), so this small regression in link time shouldn't affect
> them.
>
> Remove the explicit gdb_index gn arg now that this has a good default.
>
> 2) For symbol_level=1, make this mode actually work again after the gn swtich.
> In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
> Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
> overriden by -g2 immediately.
>
> Before this, symbol_level=1 in debug builds would produce full debug info.
> Since all bots set symbol_level=1, this might help with build speed
> on debug bots. For people who set this locally, it'll also speed up
> gdb startup time for target chrome from 39s to 13s and time from
> `run` in gdb to the program actually starting from 255s to 35s.
>
> *: clang always writes stack debug info to both .o and .dwo files, and lets
> the linker link them into the executable, so -g1 -gsplit-dwarf would make
> no sense. This was used as justification to make -gsplit-dwarf imply -g2,
> as it otherwise wouldn't have an effect.
>
> BUG=374952
>
> Review-Url: https://codereview.chromium.org/2770933009
> Cr-Commit-Position: refs/heads/master@{#459790}
> Committed: 7b26c51270TBR=dpranke@chromium.org,piman@chromium.org,tansell@chromium.org,thakis@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=374952
Review-Url: https://codereview.chromium.org/2776193002
Cr-Original-Commit-Position: refs/heads/master@{#459800}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 745ab003bddd9043058e1f19db831a9b4f0f6dbf
This change contains two parts, for full-symbol (symbol_level=2, default)
and reduced-symbol (symbol_level=1) debug builds. It has no effect on release
builds.
1.) For symbol_level=2, pass -Wl,--gdb-index to the linker. This lets the linker
write an index that lets it load binaries much faster.
gdb startup time for target chrome from goes from 60s to 10s and time from
`run` in gdb to the program actually starting from 270s to 45s.
In return, this slows down linking a bit, but for target chrome in a
debug build, it increases link time from 37s to 42s, which is better than
making people who want to use gdb wait several minutes every time they start
gdb.
There's some history here: We used to pass -Wl,--gdb-index long ago, and
then removed it in https://codereview.chromium.org/335903002/, with the
recommendation that people who want to use gdb could run build/gdb-add-index.
But running `gdb-add-index chrome` takes 73s nowadays, a lot more than the 5s
that gold needs. (Back then, gdb-add-index was faster, and gold, due to us
not yet defaulting to component builds in debug builds, was slower. Also,
people were on an older default Ubuntu and used an older gdb version.)
People who don't use gdb should use symbol_level=1 for their builds anyhow
(and bots do too), so this small regression in link time shouldn't affect
them.
Remove the explicit gdb_index gn arg now that this has a good default.
2) For symbol_level=1, make this mode actually work again after the gn swtich.
In symbol_level=1 builds, gn would pass `-g1 -gsplit-dwarf` to clang (*).
Surprisingly, -gsplit-dwarf implies -g2 with clang, so the -g1 gets
overriden by -g2 immediately.
Before this, symbol_level=1 in debug builds would produce full debug info.
Since all bots set symbol_level=1, this might help with build speed
on debug bots. For people who set this locally, it'll also speed up
gdb startup time for target chrome from 39s to 13s and time from
`run` in gdb to the program actually starting from 255s to 35s.
*: clang always writes stack debug info to both .o and .dwo files, and lets
the linker link them into the executable, so -g1 -gsplit-dwarf would make
no sense. This was used as justification to make -gsplit-dwarf imply -g2,
as it otherwise wouldn't have an effect.
BUG=374952
Review-Url: https://codereview.chromium.org/2770933009
Cr-Original-Commit-Position: refs/heads/master@{#459790}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 7b26c51270cebd5de672a155b34f30bc8282c35a
This reduces our installed APK size from ~90MB to 65 on ATV. It
reduces earth OTA size by 1.5MB and earth cast_shell size by 5MB.
Leave unwind tables for builds where we regularly use a debugger (x86
and ATV debug).
BUG=internal b/36082628
Review-Url: https://codereview.chromium.org/2770833003
Cr-Original-Commit-Position: refs/heads/master@{#459619}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: a13b58bb24fb7bc0bbc7d68296ef11a64df4989e
MSVC complains if you use noexcept with no exception handling mode specified (as we do).
This code disables the warning. noexcept on move constructors allows better optimizations
in some cases.
http://en.cppreference.com/w/cpp/language/noexcept_spec
Updates a few common classes' move constructors to use this.
Reland of https://codereview.chromium.org/2771643002 with landmine. There were some
reports of PCH headers not getting updated and the warning change no taking effect.
I investigated briefly but could not see why PCH dependencies are incorrect.
Review-Url: https://codereview.chromium.org/2769283002
Cr-Original-Commit-Position: refs/heads/master@{#459455}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: f78cc27d15ccbd1fd0c5c93aa03b939cd89b9b89
Previously we ran tests, without setting butler environment variables.
This will run into NotBootstrappedError when we try to upload test
results through logdog.
In this cl, we use logdog butler subcommand to run tests, which will set
butler environment variables before hand.
BUG=692287
Review-Url: https://codereview.chromium.org/2695963003
Cr-Commit-Position: refs/heads/master@{#456976}
Committed: de2df28c86
patch from issue 2695963003 at patchset 820001 (http://crrev.com/2695963003#ps820001)
Review-Url: https://codereview.chromium.org/2767833002
Cr-Original-Commit-Position: refs/heads/master@{#459281}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 9b15df5f68a23a7c75af0e09ee52b4add1a6f1d6
Reason for revert:
Seems to have broken Windows build with args.gn as:
> is_debug = true
> is_component_build = true
> enable_nacl = false
> is_chrome_branded = true
> symbol_level = 2
> target_cpu = "x86"
> is_win_fastlink = true
> is_clang = false
> win_console_app = true
> win_linker_timing = true
Original issue's description:
> Enable noexcept on Windows, use for a few move constructors.
>
> MSVC complains if you use noexcept with no exception handling mode specified (as we do).
> This code disables the warning. noexcept on move constructors allows better optimizations
> in some cases.
> http://en.cppreference.com/w/cpp/language/noexcept_spec
>
> Updates a few common classes' move constructors to use this.
>
> Review-Url: https://codereview.chromium.org/2771643002
> Cr-Commit-Position: refs/heads/master@{#458956}
> Committed: 76aac97386TBR=brucedawson@chromium.org,lfg@chromium.org,brettw@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review-Url: https://codereview.chromium.org/2769703007
Cr-Original-Commit-Position: refs/heads/master@{#459101}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 12c27f45b2cd8fea6c833a47d5270da42d791740
This is an attempt to reland a change that was attempted
several times already. It now includes changes to the
linux packaging expectations which previously caused
failed on the official bots.
TESTED=ninja linux_packages_all
BUG=701894
Review-Url: https://codereview.chromium.org/2748183005
Cr-Original-Commit-Position: refs/heads/master@{#459062}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: 94c4fa81c45284d0fe1e5616f52fcad56745077b
mikecase
pennymac
rnk
bcf
mbjorge
wez
sbc
erikchen
thomasanderson
krasin
baxley
kjellander
Mike Case
michaeldo
brucedawson
Nico Weber
findit-for-me
drott
sdefresne
machenbach
satorux
jwd
halliwell
thomasanderson
brettw
lambroslambrou
hzl
wittman
scottmg