When linking a weak symbol in an object against a library where the
symbol is provided with a version, the final binary gets a weak versioned
symbol reference.
It turns out weak versioned symbols still make the dynamic linker need
the symbol version, even if all symbols needed with that version are
weak.
Practically speaking, that means with bug 1634204, we now end up with
a weak versioned symbol reference to __cxa_thread_atexit_impl with
version GLIBC_2.18, and glibcs without the symbol can't fulfil that
version, even though the weak symbol is the only thing we need from that
version.
This means the check_binary changes in bug 1634204 are too
relaxed, so we revert them (although we keep the easier to read
conditions in check_dep_versions).
We also introduce a hack in stdc++compat.cpp (although it's not
technically entirely about libstdc++ compat) so that we avoid the weak
symbol reference while keeping the intended baseline for libstdc++ and
glibc.
Differential Revision: https://phabricator.services.mozilla.com/D79773
I wrote this patch to address two problems:
1. if I do `mach run` from a directory other than $topsrcdir, $objdir, or
$objdir/dist/bin, then .gdbinit will not be loaded.
2. Debugging the firefox binary will never load the JS prettyprinters in any
case.
I believe this patch fixes other problems as well, such as .gdbinit_python not being found, and the gdbpp pretty-printers not getting loaded in various situations.
The main changes of this patch are:
1. Move .gdbinit into build/ (and $objdir/build/) to delay it from getting
loaded until the search path is configured.
2. Move libxul.so-gdb.py into the correct directory.
3. Use either libxul.so-gdb.py or js-gdb.py to configure the correct
search path then load .gdbinit, and have .gdbinit load all of the
pretty-printers (Gecko and JS).
4. Use a single preprocessed file to configure the source directory. Use
relative paths within the objdir for everything else.
Differential Revision: https://phabricator.services.mozilla.com/D77589
This brings the `android-build` image very close to other build
images, paving the way for it to be folded in completely. It also
makes us more resilient in the face of upstream service interruptions.
Differential Revision: https://phabricator.services.mozilla.com/D78945
I wrote this patch to address two problems:
1. if I do `mach run` from a directory other than $topsrcdir, $objdir, or
$objdir/dist/bin, then .gdbinit will not be loaded.
2. Debugging the firefox binary will never load the JS prettyprinters in any
case.
I believe this patch fixes other problems as well, such as .gdbinit_python not being found, and the gdbpp pretty-printers not getting loaded in various situations.
The main changes of this patch are:
1. Move .gdbinit into build/ (and $objdir/build/) to delay it from getting
loaded until the search path is configured.
2. Move libxul.so-gdb.py into the correct directory.
3. Use either libxul.so-gdb.py or js-gdb.py to configure the correct
search path then load .gdbinit, and have .gdbinit load all of the
pretty-printers (Gecko and JS).
4. Use a single preprocessed file to configure the source directory. Use
relative paths within the objdir for everything else.
Differential Revision: https://phabricator.services.mozilla.com/D77589
To avoid sending identifying information, common absolute paths are patched with placeholder values. For example, devs
may place their Firefox repository within their home dir, so absolute paths are doctored to be prefixed with
"<topsrcdir"> instead.
Additionally, any paths including the user's home directory are patched to instead be a relate path from "~".
Differential Revision: https://phabricator.services.mozilla.com/D78962
To avoid sending identifying information, common absolute paths are patched with placeholder values. For example, devs
may place their Firefox repository within their home dir, so absolute paths are doctored to be prefixed with
"<topsrcdir"> instead.
Additionally, any paths including the user's home directory are patched to instead be a relate path from "~".
Differential Revision: https://phabricator.services.mozilla.com/D78962
Rather than always printing instructions at the end of the bootstrap phase, we will now create a mozconfig
file if one doesn't exist and there's configuration to be written.
Differential Revision: https://phabricator.services.mozilla.com/D78417
For standalone JS builds there are three possibilities: no-NSPR (the default),
build NSPR, or use system NSPR.
This patch makes no-NSPR the default again when not overridden by --enable-nspr-build
or --with-system-nspr. This was likely regressed by bug 1641775.
Differential Revision: https://phabricator.services.mozilla.com/D78001
clang_getAddressSpace was found as a clang 5.0+ API by comparing the "tools/libclang/libclang.exports" files in the clang source code.
"clang_getAddressSpace" exists for 5.0.0 and 10.0.0, but not for 4.0.1.
Differential Revision: https://phabricator.services.mozilla.com/D78374
When not using --with-android-ndk, NDK root is `~/.mozbuild/android-ndk-r20`.
When building this NDK path, since we use `os.path.join`, so it may include "\"
as file separator on Windows host. Then some options such as `-gcc-toolchain`
become invalid path (ex. `C:/users/makoto.mozbuildandroid-ndk-r20/`..).
So we should replace file separator with "/".
Differential Revision: https://phabricator.services.mozilla.com/D77820
When running |mach python| with python 3, it was failing when importing "enum", since it would get the python 2 backport. By making these packages only
available to python 2, we allow python 3 to import standard library packages properly.
Differential Revision: https://phabricator.services.mozilla.com/D77960
Version of NSS >= 3.27 have a pkg-config file. We're now requiring 3.53,
so while moving, just use pkg-config, which is simpler.
The old-configure check that rejected some untested platforms for
in-tree NSS is actually rejecting none: the accepted platforms cover all
the supported ones, so we remove that check.
And because building with system NSS without system NSPR doesn't make
sense, imply the latter when the former is used.
Differential Revision: https://phabricator.services.mozilla.com/D77428
At the same time, because it's now simpler to do so, set the right data
file name for big-endians, even though we don't have or produce it
(bug #1264836). Also remove USE_ICU, which is redundant with
JS_HAS_INTL_API, and actively break the build at configure time when
using --without-intl-api with Firefox because this hasn't actually
worked for close to 3 years (since bug 1402048).
Differential Revision: https://phabricator.services.mozilla.com/D77416
Versions of NSPR >= 4.10 come with a pkg-config file. We currently
depend on 4.9.2 for spidermonkey, but much more recent versions for
Firefox. 4.10 is less than a year newer than 4.9.2, and 4.10 is 7 years
old, so bumping the requirement to 4.10 is not really a big deal.
With the use of pkg-config, --with-nspr-cflags and --with-nspr-libs are
not needed.
None of the AC_TRY_COMPILE tests were any useful because
PR_STATIC_ASSERT and PR_UINT64 have been when we look for them since
4.8.6 and 4.9 respectively.
Differential Revision: https://phabricator.services.mozilla.com/D77412
As all versions of zlib >= 1.2.3.1 have a pkg-config file, and 1.2.3.1
is close to 14 years old, let's drop 1.2.3 and just use pkg-config, which
simplifies what we need to do dramatically.
Differential Revision: https://phabricator.services.mozilla.com/D77404
l10n-merge creates a full merge dir for a while now, let's
simplify the build logic to only read from that directory
during repacks and langpacks.
Differential Revision: https://phabricator.services.mozilla.com/D77023
Instead of doing this:
a) read existing file into memory
b) append new entries
c) sort all entries
d) write unique entries back to file
We now do this:
a) sort new entries
b) loop through existing file entries, one at a time, writing them to a tmp file
c) insert the new entries in between the existing file entries in lexicographic order,
and deduplicating the new entries
d) write any remaining new entries (that are lexicographically after the last
entry in the pre-existing file), again deduplicating the entries
e) move tmp file back to original file location
This avoids reading the entire file into memory which could be potentially
hundreds of MB large.
The changes in FileOperations.* are needed to support these changes, as we now
have two files that we're dealing with - reading from one and writing to the
other. We still use a Mutex (Windows) or exclusive-flock (POSIX) on the file
for the duration of the entire operation, so we should still be robust in the
face of multiple concurrently running clang processes.
Differential Revision: https://phabricator.services.mozilla.com/D76202
The configure sandbox has a list of arguments to handle, and removes
each of them when it resolves the corresponding options through e.g. a
`@depends`. When the configure sandbox is finished, what's supposed to
be left is unknown options.
The mozconfig injections adds elements to that list of arguments to
handle. The problem is that by the time the mozconfig injection happens,
some early options have already been handled by the sandbox and won't be
re-handled. Which means by the end of configure, the arguments are still
there, and the sandbox throws an error because it thinks they are for
unknown options.
Things were actually working before bug 1264527, essentially because we
had an explicit list of mozconfig variables that would be injected, and
that didn't include those early options.
So what we now do is to not actually inject those early options from
mozconfig.
Differential Revision: https://phabricator.services.mozilla.com/D76276
The expanded checks in clang 10 made arm64 builds hit CFG crashes on nsXPTCStubBase vtables on startup.
It's not clear why this doesn't happen on x86 builds. Given our current level of support for arm64, I can't really justify investigating this, although I suspect that fixing the underlying issue would be pretty much bug 1483885.
As a get-unblocked stopgap, `-guard:cf,nochecks` in clang 10 gives the same behavior as `-guard:cf` in clang 9.
Differential Revision: https://phabricator.services.mozilla.com/D76216
The "clang-9" variant of the patch is no longer present. For clang-7, the patch
file to use is now "find_symbolizer_linux.patch".
Differential Revision: https://phabricator.services.mozilla.com/D76176
Configuration values defined above `mozconfig_options` in `init.configure` are those that can't be configured in `mozconfig`. As far as I can tell there is nothing wrong *in principle* with setting `PYTHON3` in `mozconfig`, so here we just bump `mozconfig_options` above `PYTHON3` configuration.
Side note, diagnosing this failure took a *long* time. The error message that this produced ("unknown option `PYTHON3`") is useless and the underlying algos being extremely mutable, I ended up having to spend a lot of time in the debugger and monitor all the underlying changes to a bunch of mutable data structures to determine where `PYTHON3` was getting lost. A better error message would be good here but I don't know how I would begin adding it.
Differential Revision: https://phabricator.services.mozilla.com/D75635
--enable-hardware-aec-ns option does nothing so it is deleted too.
removed `hardware_aec_ns` from gyp vars since it is never used
Differential Revision: https://phabricator.services.mozilla.com/D75798
Create a new MachCommandCondition, "is_firefox_or_thunderbird" which is then used
to allow mach valgrind-test work for Thunderbird builds.
Differential Revision: https://phabricator.services.mozilla.com/D73153
iOS support for Gecko has not been tested in years and is most probably
out of date. The build system part of it, specifically the checks in
build/autoconf/ios.m4, are not trivial to port to python configure, and
they prevent other things from moving to python configure (because some
of them change value when MOZ_IOS is set).
The code is left alone, although it could probably be stripped off as
well, but I'll leave that as an exercise for someone else.
Differential Revision: https://phabricator.services.mozilla.com/D75463
If we don't do this, configure will happily think the linker kind is
"unknown", which then causes problems downstream.
Differential Revision: https://phabricator.services.mozilla.com/D75300
This patch is adding an option to push a perftest run in the CI.
It's based on :
- sparse profiles
- push_to_try
- options passed through try_task_config.json
Differential Revision: https://phabricator.services.mozilla.com/D74115
ubsan's generated code trips an optimization corner case in clang 10. This is a short-term workaround. In the best case, llvm.org/pr45835 will land a fix soon, and we can merge that for our clang-10 update and not even land this patch. However, in case we're living in anything other than the best case world, I don't want to block on that happening.
Differential Revision: https://phabricator.services.mozilla.com/D74727
ubsan's generated code trips an optimization corner case in clang 10. This is a short-term workaround. In the best case, llvm.org/pr45835 will land a fix soon, and we can merge that for our clang-10 update and not even land this patch. However, in case we're living in anything other than the best case world, I don't want to block on that happening.
Differential Revision: https://phabricator.services.mozilla.com/D74727
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
Without this, taskgraph calculates the digest based on just the files in these
directories that are in the sparse profile (I suspect this is just the
moz.build files), and will rebuild it when those files change. This changes
ensures that all files in those directories are used to calculate the digest.
Additionally, this will cause the same digest to be generted by developers
locally, since the files *are* present in the non-sparse checkout that most
developers have.
Differential Revision: https://phabricator.services.mozilla.com/D74113
Extends the desktop changes made in bug 1475141 to Android, to avoid confusion when the
browser hangs between tests, or during shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D74284
We do this to avoid unnecessarily penalizing subprocess invocations from
within mach (and all child processes) on some Linux setups.
Differential Revision: https://phabricator.services.mozilla.com/D66786
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
The license used to be LGPL so the code lived in other-licenses, but it was changed to BSD eleven years ago. Let's move it over to third_party/python/ply where it belongs.
./mach vendor python ply==3.10
`diff -r` between the original `ply` directory and the new one only comes up with the new file `third_party/python/ply/CHANGES` which isn't relevant to the functionality of the code, so this should be a no-op all told.
Differential Revision: https://phabricator.services.mozilla.com/D73341
We do this to avoid unnecessarily penalizing subprocess invocations from
within mach (and all child processes) on some Linux setups.
Differential Revision: https://phabricator.services.mozilla.com/D66786
MessagePool brings no benefit over the traditional nsIThread.
Additonally, replace some incorrect use of RefPtr for xpcom objects.
Differential Revision: https://phabricator.services.mozilla.com/D73827
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This gets rid for the need of a number of local packages (mostly related
to Gtk+3). One exception is that we now need a 32-bits version of the
xz-utils package, some -dev package depends on it, and that dependency
can't be fulfilled in the 32-bits image because we already have the
64-bits backport installed, which conflicts with it (we need both
32-bits and 64-bits package to be at the same version when installed).
The system binutils fails to link clang-7 for some reason, so we now use
our toolchain binutils instead, like we already do for newer versions of
clang.
The debian-packages docker image now needs an explicit installation of
git, because it's not pulled in via the recommends of some other
package.
For some reason, snapshot.debian.org doesn't contain the jessie-backports
archive at the same location as others, and only has a few snapshots of
the archive.
Differential Revision: https://phabricator.services.mozilla.com/D73784
This includes scripts that involve `tup`, jobs that build `tup` in automation, `tup.configure`, and related infrastructure and documentation.
Differential Revision: https://phabricator.services.mozilla.com/D73921
Now that there are only two uses of it, and there won't be more, remove
them and just use host_for_sub_configure and target_for_sub_configure
directly.
Differential Revision: https://phabricator.services.mozilla.com/D73411
As mentioned in previous change, js subconfigure used to be called from
old-configure, and some of that old setup remains to this day.
They don't really cause problems, except speed issues, especially on
Windows: arguments passed to old-configure is treated in a large shell
loop, and the more arguments are passed, the longer it takes. On my
machine, this cumulates to more than 10s! For arguments it doesn't
recognizes and doesn't use. And the environment variable js_options are
not used either, although they don't have a similar impact.
What we're doing here:
- Remove js_options from extra_old_configure_args, that leaves only
host_for_sub_configure and target_for_sub_configure there.
- Since none of the above are environment variables, we don't need to
separate out environment variables, nor to pass them down to
old-configure.
Differential Revision: https://phabricator.services.mozilla.com/D73410
js subconfigure used to be invoked from old-configure, and the
transition out of old-configure preserved the code sharing.
prepare_configure_options currently collects all the old configure
arguments, separating js_option arguments from js_option environment
variables. This distinction is necessary for old configure, but not
for python configure, so we can now handle all the js_options
similarly.
Differential Revision: https://phabricator.services.mozilla.com/D73409
Add the -X switch to ignore default include path, and tolerate proprocessor failures.
This enables the check to skip a directory that is missing headers, instead of
falling back on the default paths.
Differential Revision: https://phabricator.services.mozilla.com/D73371
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
Currently MozillaBuild with $PYTHON3 first creates virtualenv with the path from environment variable and then reexecutes with its own bundled executable. This patch forces it to run with virtualenv python when reexecuting.
Differential Revision: https://phabricator.services.mozilla.com/D72446
`llvm::make_unique` is a drop-in alternative for `std::make_unique` that isn't useful in post-C++14 world, so it was [deleted](https://reviews.llvm.org/D66259). This is the only file that calls `llvm::make_unique` as opposed to the `std` function.
Differential Revision: https://phabricator.services.mozilla.com/D72967
This patch adds support for tests metadata. A test script parser is added as
well as a new "doc" flavor that can be used to display the script info in the
command line. This parser will be the basis for building automated docs and
scripts verifications if we want to do this.
Differential Revision: https://phabricator.services.mozilla.com/D72800
* update paths to test manifest and user.js after Bug 1596567.
* make sure to use root=True when checking for existence of reftest.log.
* work around permissions errors when pushing to /data/local/tests.
* Properly handle symbolic links to the JavaScript tests for desktop
and remote Android tests.
Differential Revision: https://phabricator.services.mozilla.com/D69313
This was the case with my local rustc build today. We only use this directory for natvis files, it's fine to not have those.
Differential Revision: https://phabricator.services.mozilla.com/D72440
`os.path.realpath` in Python 3.8 now always uppercases Windows drive letter, while it was just an alias of `os.path.abspath` in Windows. This patch uses `.realpath()` consistently to get `topobjdir` to fix the incompatibility from the behavior change.
Differential Revision: https://phabricator.services.mozilla.com/D72188
Split out jsreftest and jittest files into their own packages, removing them
from the common package.
This speeds up extracting files from the common test archive for
non-jsreftest/jittest suites.
Also, remove some files from the web-platform test archive that are already
present in the common archive.
Differential Revision: https://phabricator.services.mozilla.com/D72192
The original commit message for the order files says "It's OK if these files are slightly out of date", and that's true. However, in the 11 months since then, our builds have undergone major changes that affect large numbers of final symbol names, like switching from Frontend to IR PGO, and enabling the new pass manager. I think at this point a refresh wouldn't hurt.
I generated these files by locally creating a "stage 2.5" PGO build that's both `-fprofile-use` _and_ `-finstrument-functions-after-inlining`, and otherwise following the instructions from bug 1444171. Doing this at the `use` stage rather than the `gen` stage lets us get around the problem of mixing IR and Frontend instrumentation. It also gets us a more accurate picture of the final optimizations.
I haven't exhaustively run this through Talos. I did some spot checks, most were within noise, Speedometer maaybe gets 0.6%. I don't think this is worth hogging the talos machines for a full run, we can get the results after landing.
If for no other reason, this is worth doing to reduce 8000 lines of warning LNK4037 (order file refers to a nonexistent symbol) in build logs down to about 15.
Differential Revision: https://phabricator.services.mozilla.com/D72171
When running e.g. check_symbols with extra flags like when checking
for vpx_codec_dec_init_ver when building against system libvpx, in some
configurations, the test can fail when the library flags (-l) appear
before the source file path.
The reason is that in some configurations, the compiler passes
--as-needed to the linker before both the flags and the object file
path, and the object file path is in the same position as the source
file path was. With --as-needed, -l flags are dropped if the library
wasn't needed for any of the linked code that appears *before* the flag.
So linking with `--as-needed -lfoo foo.o`, is equivalent to linking with
`foo.o` only in practice, while `--as-needed foo.o -lfoo` is equivalent
to `foo.o -lfoo`.
Differential Revision: https://phabricator.services.mozilla.com/D71456
Bug 1568994 moved the URL for the update server to application.ini. Thunderbird
uses a different hostname for the update URL; the URL path is the same.
I've added a set_config('MOZ_APPUPDATE_HOST') to Thunderbird's moz.configure
file which will override the default.
Differential Revision: https://phabricator.services.mozilla.com/D70964
The clang_rt.builtins lib files produced by the 1stage build do not include
functions necessary for 128bit integers. This functionality is required by the
OpenPGP libraries that Thunderbird is using, specifically Botan's bigint module.
When compiler-rt is built with MSVC, these functions are not included
by design.
Differential Revision: https://phabricator.services.mozilla.com/D71785
This matches up to what we were doing before the Python 3 switch. Subprocess.Popen's default encoding doesn't necessarily match up to the system encoding as reported by mozbuild.util.system_encoding, and pre-Python 3.6 the constructor doesn't have `encoding` or `errors` parameters for no apparent reason. In the meantime, do the decoding manually.
Differential Revision: https://phabricator.services.mozilla.com/D71193
Unfortunately, since the new ecdsa library has a different interface and slightly different inner workings compared to the old PyECC library, the changes to support this update are not trivial. Luckily the ecdsa library is extensible enough to allow us to adjust the library's functionality with function parameters rather than monkey-patching, as we were doing with the previous version of the code. All of these interface changes are in addition to the normal rote Python 3 updates. This was tested by running a build with and without this patch and ensuring there were no unexpected diffs.
Differential Revision: https://phabricator.services.mozilla.com/D70117
When running e.g. check_symbols with extra flags like when checking
for vpx_codec_dec_init_ver when building against system libvpx, in some
configurations, the test can fail when the library flags (-l) appear
before the source file path.
The reason is that in some configurations, the compiler passes
--as-needed to the linker before both the flags and the object file
path, and the object file path is in the same position as the source
file path was. With --as-needed, -l flags are dropped if the library
wasn't needed for any of the linked code that appears *before* the flag.
So linking with `--as-needed -lfoo foo.o`, is equivalent to linking with
`foo.o` only in practice, while `--as-needed foo.o -lfoo` is equivalent
to `foo.o -lfoo`.
Differential Revision: https://phabricator.services.mozilla.com/D71456
The V8 code in the new engine uses implicit constructors with wild abandon, and it doesn't seem like a good use of time to try upstreaming a patch to remove them.
Depends on D71355
Differential Revision: https://phabricator.services.mozilla.com/D71356
One of the recent changes made it so that the test doesn't start on its own unless the URL has "raptor".
I've confirmed that this
- Does not swamp out the profdata file
- Does not regress displaylist-mutate
- Improves the webaudio score
Differential Revision: https://phabricator.services.mozilla.com/D71197
Currently the linux64-clang-9-win-cross toolchain depends on the win64-clang-cl toolchain for a few files. This causes very long lead times when toolchains are rebuilt, because of the un-parallelizable chain of tasks win64-clang-cl -> linux64-clang-9-win-cross -> builds.
As a partial mitigation, this patch adds a single-stage clang-cl build for consumption by the cross toolchain. It's not a very high quality build, but good enough for the purpose it serves, while being faster to build.
Differential Revision: https://phabricator.services.mozilla.com/D70254
--HG--
rename : build/build-clang/clang-win64.json => build/build-clang/clang-win64-1stage.json
extra : moz-landing-system : lando
This commit removes `test_fix_stack_using_bpsyms.py`. That test can't easily be
modified to work with `fix_stacks.py` because it relies on internal
implementation details of `fix_stack_using_bpsym.py`. The unit testing done in
the `fix-stacks` repo provides test coverage that is as good or better.
Differential Revision: https://phabricator.services.mozilla.com/D66924
--HG--
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
The `linux64-clang-9-cross` toolchain was forked from `linux64-clang-9` in https://hg.mozilla.org/integration/autoland/rev/ca923afe3ed4 in order to pick up a patch for Windows compilation.
This is no longer necessary for two reasons:
1. Windows builds stopped depending on that patch in bug 1608460.
2. Even if we still needed that patch, the `linux64-clang-9` toolchain gained all of the Windows patches in bug 1618473.
Therefore the `clang-dist` task can go back to using unmodified `linux64-clang-9`.
Differential Revision: https://phabricator.services.mozilla.com/D70263
--HG--
extra : moz-landing-system : lando
Patches that are applied on top on `clang-10` repo are based on the original
patches from our trunk and have been rebased on top of `clang-10`.
Please see as an example: `find_symbolizer_linux.patch` copied to `find_symbolizer_linux_clang_10.patch`.
Differential Revision: https://phabricator.services.mozilla.com/D70063
--HG--
rename : build/build-clang/clang-linux64.json => build/build-clang/clang-10-linux64.json
rename : build/build-clang/find_symbolizer_linux.patch => build/build-clang/find_symbolizer_linux_clang_10.patch
rename : build/build-clang/llvmorg-11-init-4265-g2dcbdba8540.patch => build/build-clang/llvmorg-11-init-4265-g2dcbdba8540_clang_10.patch
rename : build/build-clang/rG7e18aeba5062.patch => build/build-clang/rG7e18aeba5062_clang_10.patch
rename : build/build-clang/rename_gcov_flush.patch => build/build-clang/rename_gcov_flush_clang_10.patch
rename : build/build-clang/tsan-hang-be41a98ac222.patch => build/build-clang/tsan-hang-be41a98ac222_clang_10.patch
rename : build/build-clang/unpoison-thread-stacks.patch => build/build-clang/unpoison-thread-stacks_clang_10.patch
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
This also does a few remaining python 2 incompatible changes to
.configure files.
Differential Revision: https://phabricator.services.mozilla.com/D69538
--HG--
extra : moz-landing-system : lando
This adds the ability to do four-stage PGO builds. This was surprisingly straightforward thanks to PGO being a well-supported scenario in LLVM's cmake.
For reference, the stages are:
stage1: Initial build with gcc
stage2: Instrumented build using stage1
stage3: Train by using the instrumented stage2 to build the clang tree
stage4: Optimize using the stage3 compiler and the profdata created with it
Differential Revision: https://phabricator.services.mozilla.com/D69080
--HG--
extra : moz-landing-system : lando
Separating out the mechanical/"boring" changes to make the next patch more clear. This patch adds the ability to build a fourth stage that for now doesn't do anything special.
I changed to using >= to make it more obvious that e.g. "here is what's going to happen for stage 2" -- the off-by-one was too hard on my brain.
Differential Revision: https://phabricator.services.mozilla.com/D69079
--HG--
extra : moz-landing-system : lando
Otherwise, PGO builds would fail to find asan at stage2 because the instrumented build uses `LLVM_BUILD_RUNTIME=No`.
Differential Revision: https://phabricator.services.mozilla.com/D69082
--HG--
extra : moz-landing-system : lando
This will partially atone for making builds longer with PGO.
Depends on D69618
Differential Revision: https://phabricator.services.mozilla.com/D69620
--HG--
extra : moz-landing-system : lando
Using @checking doesn't go well with the virtualenv creation, so print
the version information after the fact. And do so uniformely for python
2 and python 3.
Differential Revision: https://phabricator.services.mozilla.com/D69529
--HG--
extra : moz-landing-system : lando
This is yet another cargo-cult from virtualenv_python2, which is not
necessary because by the time we reach virtualenv_python3, the mozconfig
configure *has* been injected already.
Differential Revision: https://phabricator.services.mozilla.com/D69528
--HG--
extra : moz-landing-system : lando
It was cargo-culted from virtualenv_python2, but is not necessary
because virtualenv_python3 is not going to re-execute python, which is
what the dependency is there to avoid.
Differential Revision: https://phabricator.services.mozilla.com/D69527
--HG--
extra : moz-landing-system : lando
This was cargo-culted from virtualenv_python2, but this is not
necessary: currently, the only way configure code will execute with
python 3 is if something uses the configure sandbox from python 3, not
configure. Only configure itself is meant to re-execute itself with
python, so we don't want python 3 to re-execute.
We'll be swapping virtualenv_python2 and virtualenv_python3 later, when
switching to python 3.
Differential Revision: https://phabricator.services.mozilla.com/D69526
--HG--
extra : moz-landing-system : lando
* We change the SDK version to use build tools 29.0.3;
* We change `build_tools_version` from a list to a string;
* We convert `android_build_tools` to work correctly with the above change;
* We set the build tools version in configure, as gradle needs to access it
in a subsequent patch.
Differential Revision: https://phabricator.services.mozilla.com/D69631
--HG--
extra : moz-landing-system : lando
Switched handling of AppUpdate:URL from it being required to it being optional, much as Crash Reporter:serverurl is handled.
Differential Revision: https://phabricator.services.mozilla.com/D68606
--HG--
extra : moz-landing-system : lando
We only enabled hardening with an explicit --enable-hardening because we
needed a patch. That patch was applied to upstream clang 8.0.1, so we
can now enable automatically whenever using the right version.
The explicit --enable-hardening was also not applied to win64-aarch64
debug builds, and this indirectly enables it there too, matching other
debug builds. This also avoids breaking debug builds when enabling
winchecksec on cross builds.
Differential Revision: https://phabricator.services.mozilla.com/D68161
--HG--
extra : moz-landing-system : lando
This is required for llvm-mt, which building winchecksec will require.
We do a dummy change to build-clang.sh so as to change the toolchain
index hash.
Differential Revision: https://phabricator.services.mozilla.com/D68153
--HG--
extra : moz-landing-system : lando
This is being added to facilitate moving generation of the update URL to Rust (Bug 1567286). Once that has been completed, we should be able to remove the update URL from its current location in firefox.js so that it is not being duplicated in application.ini.
Differential Revision: https://phabricator.services.mozilla.com/D43300
--HG--
extra : moz-landing-system : lando
This needs a few adjustments to the autobinscope script because running
binscope currently creates an HTML file in the binscope directory, and
when multiple binscopes run at the same time (which happens during the
build with the changes to run it on all executables and libraries), all
but one fail to open the HTML file for write access.
So add a flag to create that file in a temporary directory.
While here, remove log_file_path, which hasn't been used since
bug 1448306.
Differential Revision: https://phabricator.services.mozilla.com/D67422
--HG--
extra : moz-landing-system : lando
After cargo 7caa161, which was included in rust 1.43 nightly 2020-02-23 as part of rust 11530de, if you don't have rustc installed in the normal place (which our CI builders don't) then you need to specify RUSTC explicitly during cargo metadata or else the call will fail. In our build system, the RUSTC wasn't being passed through in RunCbindgen.py.
Differential Revision: https://phabricator.services.mozilla.com/D68086
--HG--
extra : moz-landing-system : lando
Tom Ritter
Razvan Maries
Mike Hommey
Steve Fink
Nick Alexander
Henri Sivonen
Noemi Erli
Mitchell Hentges
Dorel Luca
Sylvestre Ledru
Jan de Mooij
Makoto Kato
John Paul Adrian Glaubitz
Coroiu Cristina
Bogdan Tara
Ricky Stewart
Axel Hecht
Cameron McCormack
julianwels
Kartikaya Gupta
Cosmin Sabou
David Major
Chris AtLee
Rob Lemley
Corentin Arnould
Thomas Duellmann
Emilio Cobos Álvarez
Sebastian Streich
Edwin Takahashi
Nathan Froyd
Tarek Ziadé
Jean-Yves Avenard
Narcis Beleuzu
Tom Prince
Geoff Brown
Dana Keeler
Bob Owen
Csoregi Natalia
André Bargull
Andrew Sutherland
Adam Gashlin
Andreea Pavel
Kagami Sascha Rosylight
Daniel Varga
Bob Clary
Andi-Bogdan Postelnicu
Stefan Hindli
shravanrn@gmail.com
Brindusan Cristian
Tooru Fujisawa
Iain Ireland
Jesse Schwartzentruber
Tetsuharu OHZEKI
Nicholas Nethercote
Andrea Marchesini
Dzmitry Malyshau
Mihai Alexandru Michis
Simon Giesecke
Oana Pop Rus
Arthur Iakab
Lupita Arroyo
Aaron Klotz
Sebastian Hengst
Kirk Steuber
Stephen A Pohl
James Willcox
Ian Neal
Christian Holler