I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
I changed DelegatedQueryInterface and CallMethod to be non-static
methods rather than taking an explicit |self| parameter.
I did a tiny bit of cleanup in the nsIXPConnectJSObjectHolder case of
DelegatedQueryInterface().
There is already a method nsXPCWrappedJS::CallMethod() with the same
signature, but it is a shim, so I inlined it into the version in
XPCWrappedJSClass.cpp.
I also fixed up a few comments that mention nsXPCWrappedJSClass.
The new comments starting with "We now need to enter the realm" were
written by Boris, and are a little more explicit so they are easier to
understand.
I renamed DebugDump() to DebugDumpInterfaceInfo() to be more
informative.
Differential Revision: https://phabricator.services.mozilla.com/D26422
--HG--
extra : moz-landing-system : lando
Module::AddFunction assumes that any time we add a function, it is
preferable to use that instead of the corresponding external
symbol (which could be anything). The former show up in Breakpad symbol
files as FUNC lines, and the latter as PUBLIC lines.
For Module::AddFunction to be effective, we have to parse all the
external symbols for a module first, and then discover all the actual
functions. But the Linux symbol dumping code does the reverse: it first
parses all the DWARF information (including .debug_info, which adds any
relevant functions) and then parses the ELF symbol table. This ordering
means that we wind up emitting PUBLIC lines for which corresponding FUNC
lines already exist. These duplicate PUBLIC lines take up roughly 10%
of the size of a libxul symbol file (~30MB), and are completely unnecessary.
The fix is simple: we should reverse the order in which we parse ELF
symbols and DWARF debug information.
Differential Revision: https://phabricator.services.mozilla.com/D25116
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
Disable tests as they fail constantly on xpcshell-8 on windows10-aarch64.
Bug 1536221 is filed for investigating why the crashreporter tests still fail.
Differential Revision: https://phabricator.services.mozilla.com/D23940
--HG--
extra : moz-landing-system : lando
clang-cl only acts on five MSVC warning flags: 7219c7e9af/clang/include/clang/Driver/CLCompatOptions.td (L188-L197)
With MSVC now unsupported, most -wdNNNN have no effect and can be removed.
This patch converts the five supported warnings to their clang spellings, as preparation for a subsequent patch that will remove all remaining `[/-]w[edo][0-9]{4}`.
Differential Revision: https://phabricator.services.mozilla.com/D22582
--HG--
extra : moz-landing-system : lando
aarch64 windows uses a custom unwind information format to describe
how to unwind from within functions. We need to parse that
information to describe to Breakpad how to unwind stacks for minidump
analysis.
Differential Revision: https://phabricator.services.mozilla.com/D20541
--HG--
extra : moz-landing-system : lando
Consequently, this removes:
- MOZ_LIBPRIO, which is now always enabled.
- non_msvc_compiler, which is now always true.
- The cl.py wrapper, since it's not used anymore.
- CL_INCLUDES_PREFIX, which was only used for the cl.py wrapper.
- NONASCII, which was only there to ensure CL_INCLUDES_PREFIX still
worked in non-ASCII cases.
This however keeps a large part of detecting and configuring for MSVC,
because we still do need it for at least headers, libraries, and midl.
Depends on D19614
Differential Revision: https://phabricator.services.mozilla.com/D19615
--HG--
extra : moz-landing-system : lando
1. The unsetting of LD_LIBRARY_PATH is removed, because it's no longer
necessary and interferes with environments where it's necessary to find
"system" libraries like GTK; see bug 1472589 comment #1 through #4.
2. The Snap package manifest adds a dependency on the libcurl package,
so that the crash reporter can send the report. This uses the GnuTLS
variant because we're already pulling in GnuTLS as a dependency of some
other packages (FFmpeg and CUPS, but also the non-GnuTLS cURL packages
depend on it anyway via OpenLDAP).
Differential Revision: https://phabricator.services.mozilla.com/D18625
--HG--
extra : moz-landing-system : lando
This includes some assorted fixes from upstream plus an adaptation of the
patch in b988fa74ec18de6214b18f723e48331d9a7802ae which includes heap memory
regions in the minidump. Since our support for that is more extensive than
upstream breakpad the resulting change reflects this. Last but not least the
fixes for bug 1489094 and bug 1511140 were split out as patches to be applied
to the unmodified breakpad sources. They will be reintegrated as soon as we
fork breakpad for good.
Differential Revision: https://phabricator.services.mozilla.com/D16326
--HG--
extra : moz-landing-system : lando
We currently rely on WIN_DIA_SDK_BIN_DIR being passed, but we can
actually derive it from the DIA SDK directory. So we now do that, except
when it's given explicitly.
While in the vicinity, move the dia2.h check to python configure.
With WIN_DIA_SDK_BIN_DIR being derived and not set when dia2.h is not
found, we don't really need MSVC_HAS_DIA_SDK anymore, so we just check
for WIN_DIA_SDK_BIN_DIR to determine whether to build dump_syms or not.
One exception to the above is when WIN_DIA_SDK_BIN_DIR is passed in,
which we only keep for the in-tree mozconfigs for now. We'll remove that
possibility after bug 1523201.
Depends on D17892
Differential Revision: https://phabricator.services.mozilla.com/D17893
--HG--
extra : moz-landing-system : lando
We can't run dump_syms without the DIA SDK binary directory in $PATH
because dump_syms requires the DIA dll from there.
Obviously, the corresponding test can't run if the DIA SDK binary
directory is not known (rather than when the dia2.h header is not found,
since the build system currently relies on WIN_DIA_SDK_BIN_DIR being
given manually).
Differential Revision: https://phabricator.services.mozilla.com/D17892
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Because the .xdata format on ARM64 can only encode sizes up to 1M (much too small for our JIT code regions), we register a function table callback to provide RUNTIME_FUNCTIONs at runtime. Windows doesn't seem to care about the size fields on RUNTIME_FUNCTIONs that are created in this way, so the same RUNTIME_FUNCTION can work for any address in the region. We'll set up a generic one in RegisterExecutableMemory and the callback can just return a pointer to it.
Differential Revision: https://phabricator.services.mozilla.com/D16261
--HG--
extra : moz-landing-system : lando
With `ac_add_options --enable-project=tools/crashreporter` in a
mozconfig, `./mach build` builds minidump_stackwalk, dump_syms
and fileid.
One caveat is that due to limitation in how the build system works
currently, it's cumbersome to keep dump_syms as a host program for
Gecko, and to make it a target program for this project. For now,
keep it as a host program. We're not going to use it on automation,
but it's still convenient to have for quick local builds (I've had
to resort to awful hacks downstream).
Differential Revision: https://phabricator.services.mozilla.com/D16299
--HG--
extra : moz-landing-system : lando
We have prebuilt dump_syms binaries in toolkit/crashreporter/tools/win32 from
the days when we didn't build it as part of the build. There's one per MSVC
version, since the APIs it uses are version-specific, but we don't actually
support building with the MSVC versions corresponding to the binaries in that
directory anymore, so we should just remove them.
The only code change necessary here is changing the functional test to skip
running the test if a dump_syms binary isn't available.
MozReview-Commit-ID: IBuJZMVfv7C
Differential Revision: https://phabricator.services.mozilla.com/D15717
--HG--
extra : moz-landing-system : lando
Andrew McCreight
Ciure Andrei
Sylvestre Ledru
Randall E. Barker
Csoregi Natalia
Narcis Beleuzu
Nicholas Nethercote
Jan Varga
Christoph Kerschbaumer
Mark Banner
Nathan Froyd
Edwin Gao
David Major
Dorel Luca
Mike Hommey
Jed Davis
inspiro
Gabriele Svelto
Myk Melez
Sebastian Hengst
Kris Maglione
Aaron Klotz
Daosheng Mu
Ehsan Akhgari
Ted Mielczarek