The GNU_AS check in old-configure depended on running with the value
of $AS before it gets reset to just be the C compiler, which breaks when
we move setting AS into moz.configure.
This patch moves the GNU_AS check to toolchain.configure and changes it
so that it works when the assembler is the C compiler. We do have to
fix things slightly for clang, because the previous check was
succeeding, but not because of clang: it was detecting the presence of
"GNU" in the output for GNU ld/gold and a message about the GNU GPL.
This is a fairly straightforward port of the AS tool checks from old-configure
to toolchain.configure. AS is a little quirky in that we currently do a
normal-looking check for it, but then override that value to be the C compiler
for non-Windows builds, and ml[64]/armasm64 for Windows builds.
After migrating those checks, the only things left in the MOZ_DEFAULT_COMPILER
macro in compiler-opts.m4 were some unused bits, so I removed them:
* Setting of CPP/CXXCPP, which are set in toolchain.configure now
* Setting HOST_LDFLAGS to empty, which doesn't seem particularly useful.
There was also a quirky old test that the assembler was ml[64] when js-ctypes
is enabled that I removed, I don't think it provides any value since this
patch will ensure that we're using the right assembler for Windows builds.
This setup seems to work well enough to enable me to link
HOST_SIMPLE_PROGRAMS with an AArch64-cross setup. Necessary library
paths are passed to the linker via -LIBPATH and HOST_LDFLAGS rather than
letting MSVC fish them out of the environment. The change to
HOST_SIMPLE_PROGRAMS to pass HOST_LDFLAGS was necessary for this to
work, in addition to the HOST_LINKER changes.
-Wtautological-overlap-compare is an opt-in warning added in clang 3.5. It warns about overlapping comparisons that are always true or false, such as:
if (x > 4 || x < 10) {} // warning! always true
int b = x < 2 && x > 5; // warning! always false
return x > 4 || x < 10; // warning! always true
https://clang.llvm.org/docs/DiagnosticsReference.html#wtautological-overlap-compare
There are currently no -Wtautological-overlap-compare warnings in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D3477
--HG--
extra : rebase_source : e6aa211a338633e5fb7507b3a8f341709d72d6c9
This opt-in warning catches bugs where a constructor modifies a constructor parameter that shadows member variable name. The code probably intended to change the member variable value, not the paramter. There are currently no -Wshadow-field-in-constructor warnings in mozilla-central.
https://clang.llvm.org/docs/DiagnosticsReference.html#wshadow-field-in-constructor-modified
Differential Revision: https://phabricator.services.mozilla.com/D3822
--HG--
extra : rebase_source : 604ff90e036d536955db41351ee9ee97e8424d92
extra : intermediate-source : 712f538afc160f4efae2383130727edbd1dd70f6
extra : source : 300fff9a58515c7cac0647afc9ccc0e69bc8c5cb
-Wfloat-overflow-conversion detects when a constant floating point value is converted to an integer type and will overflow the target type.
https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-overflow-conversion
-Wfloat-zero-conversion detects when a non-zero floating point value is converted to a zero integer value.
https://clang.llvm.org/docs/DiagnosticsReference.html#wfloat-zero-conversion
There are currently no -Wfloat-overlap-conversion warnings in mozilla-central. There is one -Wfloat-zero-conversion warning in a webrtc test. It doesn't block enabling this check because the webrtc tests are not compiled with warnings-as-errors.
media/webrtc/trunk/webrtc/modules/audio_coding/audio_network_adaptor/frame_length_controller_unittest.cc:255:54 [-Wfloat-zero-conversion] implicit conversion from 'const float' to 'int' changes non-zero value from 0.045000002 to 0
We can't enable all -Wfloat-conversion warnings (for any implicit conversion of a floating-point number into an integer) because there are currently over 1400 warnings. I spot checked a few of these -Wfloat-conversion warnings. I didn't find any obvious bugs, but there is some suspicious code, such as implicit conversions of floats to bools.
Differential Revision: https://phabricator.services.mozilla.com/D3476
--HG--
extra : rebase_source : 589be9e593749c7000b1f89ca155e4f95a487f8f
Warn about C++ constructs whose meaning change in C++2a.
https://clang.llvm.org/docs/DiagnosticsReference.html#wc-2a-compat
So far the only -Wc++2a-compat check that I know of is for valid pre-C++2a code that inadvertently parses as C++2a's new <=> "spaceship" comparison operator. `f<&A::operator<=>();` is an example of a warning reported for a real project on GitHub. That code can be rewritten as `f< &operator<= >();`.
There are currently no -Wc++2a-compat warnings in mozilla-central.
Differential Revision: https://phabricator.services.mozilla.com/D3478
--HG--
extra : rebase_source : 4ec8147ad3fe2d1ef7c543d100c660a000385786
Our version check is removed as well, as the current required rustc version for
Firefox includes all features required to build with tup.
Differential Revision: https://phabricator.services.mozilla.com/D3847
--HG--
extra : moz-landing-system : lando
When valgrind prints out backtraces, it prints raw addresses and symbol
names, but that doesn't help find the exact code that caused the errors,
because we don't know where the libraries are loaded.
With --sym-offsets=yes, it adds the offset from the symbol, which allows
to find the relevant code in the binary.
For some reason, clang 6 crashes with a stack overflow on PGO + LTO on
Linux 64 bits. Clang 7 doesn't, but has other problems.
After some bisecting, I found the following:
- r322684 is the first revision that is broken on the release_60 branch.
- that revision is a cherry pick of r322313 from trunk, which is
similarly broken.
- trunk was fixed by r322325, which, funnily enough, predates when
r322313 was cherry-picked.
While the change from r322325 is relatively large, mixing multiple
different changes in a single commit, there also haven't been
significant changes to the same file on trunk since (one macro name
change, one documentation change, and a change related to debug info),
which would tend to indicate the change is not going to break anything,
or at least not more than upgrading to clang 7 would.
The exact part that fixes the issue could probably be found in this
large commit, but I didn't feel like digging into it further considering
the above.
In order to support operator==() for tagged enum, we have to bump the version to
0.6.2.
Differential Revision: https://phabricator.services.mozilla.com/D3932
--HG--
extra : moz-landing-system : lando
yasm doesn't support aarch64, and trying to use GNU as with an MSVC
build seems like sadness waiting to happen. Instead, we'll generate our
own assembly file that armasm64 will accept.
This change switches most CI builds to clang, with a few exceptions:
- valgrind builds, until bug 1481670 is figured out.
- PGO and nightly builds, until that's fully tested.
- coverage builds, per bug 1471339 comment 17.
- base toolchain builds, to keep some builds on GCC even when we're
fully switched to clang.
- any build that doesn't use build/unix/mozconfig.linux (e.g. probably
all those driven by autospider.py, maybe others).
This change adds a voluptuous schema for build system telemetry, replacing
the existing json schema file. Using voluptuous will make it easier to work
with the schema from Python code in the build system. A future commit will
use a Python module to provide a mach command to convert the voluptuous
schema to json schema format for consumption by other systems.
Differential Revision: https://phabricator.services.mozilla.com/D2840
--HG--
extra : rebase_source : 067995385334d1dbc123f2db4245ef4e69d076c3
In some rare cases, it is possible for one of the eh_frame sections'
original address to be larger than the address of the injected code
section, which is added before the first executable section. Namely,
this happens in the rare case where that eh_frame section is smaller
than the injected code section, and is adjacent to the first executable
section. We obviously want to move the eh_frame sections in that case,
since one of them is in the way.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
We're currently using NDK r15c, which is rather old, and happens to come
with a buggy gold linker. Let's use a more recent NDK, with a fixed
linker.
Unfortunately, we're currently at NDK API level 9, which the newer NDK
doesn't provide for x86 anymore. But that corresponds to Gingerbread
(2.3), which we've long stopped supporting. On the SDK side, we already
dropped support of versions before Jelly Bean, so we can do the same on
the NDK side. That corresponds to API level 16. So let's just use that
as a baseline.
Another change in the newer NDK is that the target-name changed from
i386-linux-android to i686-linux-android, so adjust for that in the
android x86 mozconfigs.
This change switches most CI builds to clang, with a few exceptions:
- valgrind builds, until bug 1481670 is figured out.
- PGO and nightly builds, until that's fully tested.
- coverage builds, per bug 1471339 comment 17.
- base toolchain builds, to keep some builds on GCC even when we're
fully switched to clang.
- any build that doesn't use build/unix/mozconfig.linux (e.g. probably
all those driven by autospider.py, maybe others).
We already copy the 64-bits libraries, but don't copy the 32-bits
libraries, which prevents building for linux32 by default.
Incidentally, this also makes the clang build system build the 32-bits
compiler-rt libraries, allowing e.g. 32-bits PGO.
Bug 1423822 moved the injected code section before the .text section.
When linking with lld, the text section is usually page aligned, and
starting a PT_LOAD. We inject code at the beginning of the PT_LOAD,
which means the PT_LOAD is going to be extended at least a page
downwards. And it means the preceding PT_LOAD can't finish in that same
page, so the overhead of the injected code is needs to account for the
page alignment.
If the .eh_frame_hdr and .eh_frame sections are not between the elfhack
relocation and elfhack code sections, it's not going to change anything
to try to move it, so don't even try.
While here, adjust the adjacency test to error out when the section name
doesn't match, and account for the fact that the eh_frame_hdr section
might appear after eh_frame.
--HG--
extra : rebase_source : 7d3525abe75b5a014b39ce0bd406e8f78592ec39
All CI builds for linux32 have been running on 64-bits hosts for a long
while now, and there are no 32-bits hosts left. We can remove the
special-casing that makes the linux32 builds behave differently
depending on the bit-width of the host.
Furthermore, configure has been able to deal with adding -m32 on its
own, so we don't need to add it to $CC/$CXX manually anymore.
We already copy the 64-bits libraries, but don't copy the 32-bits
libraries, which prevents building for linux32 by default.
Incidentally, this also makes the clang build system build the 32-bits
compiler-rt libraries, allowing e.g. 32-bits PGO.
We only enable libstdc++ compat on Android for the host parts, and
in practice, the target part has it not enabled at the moment because
libstdc++ can't be found. But making the clang toolchain capable of
building for x86 changes the deal for Android x86.
If the .eh_frame_hdr and .eh_frame sections are not between the elfhack
relocation and elfhack code sections, it's not going to change anything
to try to move it, so don't even try.
While here, adjust the adjacency test to error out when the section name
doesn't match.
--HG--
extra : rebase_source : 4b31712576fd3472bb94a2b9ab9542253f04cba8
Somehow, when building with LTO, clang can end up creating a eh_frame
section with only one, empty, entry (which just looks like a 4-bytes
long section full of 0x00).
--HG--
extra : rebase_source : 385c05c7e447fe1c4bc261b79c7d56138e268458
We need to add mappings for target.cpu to MSVC's arm64 name for
determining various paths, and we need to add an extra case to
get_vc_paths so the compiler can find all the necessary DLLs.
This patch adds JaCoCo as a dependency for the geckoview androidTest configurations, as well as
the `mach android archive-geckoview-coverage-artifacts` command, and the `--enable-java-coverage`
mozconfig flag.
MozReview-Commit-ID: 36jNAzK44g3
--HG--
extra : rebase_source : 9edc37913a3929ad045270c601c77791d122e363
For the same reason test-array.c and test-ctors.c need to be built
explicitly without LTO.
--HG--
extra : rebase_source : d037ef7cf1dd2d278c2918dbfee5b4f4c213e408
When linking with ld.bfd or gold, this changes the PT_LOAD in which the
elfhack code section ends up, making it go in the same one as .init, .text,
etc. rather than .rel.*. When linking with lld, this completely
avoids doing a PT_LOAD split, because lld already splits .rel.* and
.text.
--HG--
extra : rebase_source : 1f69b8f4b48b055892ea24eaa6226859cc4ffd50
We treat segments overlapping as a fatal error, rather than a condition
to do nothing, because it happening is usually the result of some bad
assumptions on the input ELF, and we don't want to silently ignore
those.
However, there are cases where a setup /could/ lead to overlapping
segments, but would be skipped because elfhack wouldn't be a win
anyways. By checking segments overlap later, we allow those to not
hard fail.
--HG--
extra : rebase_source : deca2051722aeaa959c5e4dae06642908f6d843a
The current check makes assumption wrt what PT_LOAD the injected sections
end up in, and won't work with upcoming changes.
--HG--
extra : rebase_source : b7cfb65ea13c16f977fe523aaf9f39eafeb2cdce
Summary:
The plan is to also expose perfecthash.py from this module on the python path.
This also allows us to stop using explicit module loading to load make_dafsa.py.
make_dafsa.py was moved into tools/ to avoid any extra python files from
accidentally ending up on the python path.
Reviewers: froydnj!
Tags: #secure-revision
Bug #: 1479484
Differential Revision: https://phabricator.services.mozilla.com/D2614
--HG--
rename : xpcom/ds/make_dafsa.py => xpcom/ds/tools/make_dafsa.py
When compiling C/C++ sources via Rust build scripts there's no point in
enabling warnings-as-errors as all such code is third-party code.
MozReview-Commit-ID: 5pGH6w9ZE2I
--HG--
extra : rebase_source : ad36be6aed39d55055728f85b799adf5f0cf0f4b
https://github.com/rust-lang/rust/issues/52694 is a miscompilation I
found in rust when it uses system llvm 5 or 6, that was fixed 5 months
ago in the llvm rust bundles. This may or may not affect clang, but
considering it was also reported to upstream llvm independently of rust,
it's better to side with caution.
It doesn't affect 3.9, and bug 1478919 got rid of the last use of clang
5 (except for clang-tidy, but that's not used to compile).
The patches come from the llvm trunk from 5 months ago, so they're
already in our clang 7 snapshots.
Windows static analysis builds are still using an old trunk, but are
stuck on bug 1427808. They're "only" for static analysis, though.
--HG--
extra : rebase_source : f4fce69eb7c69b6245518a1bad37e04236c7075b
This was cargo-culted from the asan/tsan mozconfigs, but is not necessary
for builds without sanitizers.
--HG--
extra : rebase_source : 41bad4761f424410cb7a099ecaecce8a86becf59
JS, at least, doesn't need bindgen at this point. If JS does start
requiring bindgen under certain build configurations, we'll have to
figure out what to do about the bindgen dependency at that point:
require bindgen always, or just require bindgen for the
configuration(s).
Summary:
This adds a clangcl flag to gyp.mozbuild and then uses that to set the same
warnings flags for clang-cl as for clang.
Reviewers: dmajor
Tags: #secure-revision
Bug #: 1478000
Differential Revision: https://phabricator.services.mozilla.com/D2427
--HG--
extra : rebase_source : 6137d2f59e5504d448d4fb32a7e734756ff76afa
Summary:
We're currently returning a fake value on all of our automation builds. Might
as well not run the script at all.
Tags: #secure-revision
Bug #: 1371485
Differential Revision: https://phabricator.services.mozilla.com/D1803
--HG--
extra : rebase_source : 20717372c15547b35759ff69088aea1ca92b7198
This adds just enough host shared library support for this one use case,
but also takes shortcuts, because fully supporting host shared library
is a deep rabbit hole I'm not ready to take just to fix --enable-lto
--enable-clang-plugin on mac builds.
One downside is that one my machine the plugin now takes > 80s to build,
instead of 15s before, thanks to the lack of unified sources.
--HG--
extra : rebase_source : bf52a72a01d4e3eb77cf52b646b19734b9273075
Currently, --enable-lto just implies --enable-linker=lld, which
essentially only works on Linux, and assumes one can't do lto with
anything other than lld. Which is not true. As a matter of fact, even
ld.bfd can do lto, as long as the gold plugin for llvm is available,
or when doing lto with GCC instead of clang.
Anyways, to allow more lto setups, we adapt the --enable-linker setup
to:
- work on macOS, which it currently doesn't, and add support for the mac
linker (ld64), which, unfortunately, doesn't have a clean way to be
detected, so work around that.
- default to lld if lto is enable, no linker was explicitly given, the
compiler is clang *and* the build target is not macOS.
--HG--
extra : rebase_source : 1dab2ad6230d18e7f4285943e76352e23b987d4e
Because we have no linking configure test in python configure (yet), we
just make old-configure tests use LINKER_LDFLAGS, and make those flags
added to LDFLAGS by old-configure at the same time.
--HG--
extra : rebase_source : 80ab7c5021c7ddd1b53d58ef76cd4372a524d3cb
