Replay, moajemalloc_info, phc, and memory needed additional
pieces (mostly Printf.cpp and dependencies) to build
successfully on Windows.
Depends on D114651
Differential Revision: https://phabricator.services.mozilla.com/D114652
- Add missing include directives and forward declarations.
- Remove some extra include directives.
- Add missing namespace qualifications.
- Move include directives out of namespace in toolkit/xre/GlobalSemaphore.h
Differential Revision: https://phabricator.services.mozilla.com/D98894
A long standing issue is that MOZ_ASSERT and related don't print stack
traces in debug builds when they're directly or indirectly emitted from
non-libxul code. Moving WalkTheStack to mozglue alleviates the problem.
It's also not printing stack traces when emitted from C code (and for
some C third party libraries, we do redirect assert to MOZ_ASSERT),
which we solve by making the corresponding API available without C++
(which WalkTheStack being a static method of the nsTraceRefCnt class
didn't allow, or the use of a closure on Android).
This requires some adjustements to headers that indirectly assume that
Assertions.h includes ErrorList.h through nsError.h through nscore.h
through nsTraceRefcnt.h.
We also remove TestStackCrawl.cpp because it hasn't been built since
bug 158528, 19 years ago.
Differential Revision: https://phabricator.services.mozilla.com/D108913
In the case of FramePointerStackwalk, the caller gives a pointer to the
top-most frame to walk from. There isn't really a reason to give a
number of frames to skip, as the right frame pointer could be given in
the first place if that was really necessary. And in practice, it's
hasn't been used so far.
In the case of MozStackWalkThread, the caller presumably doesn't know
what the thread the stack is being walked for is doing, and it would be
a guesswork to pass a valid number of frames to skip. In practice, it's
also not used.
The aSkipFrames is already a footgun on MozStackWalk (and we're going to
change that in bug 1515229), we don't need to keep a footgun on these
other stack walking methods.
Differential Revision: https://phabricator.services.mozilla.com/D108563
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses, and the updater, for which we keep using vsnprintf.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
Instead of snprintf.
Because some standalone code uses those functions directly or indirectly,
and PrintfTarget lives in mozglue, they now need to depend on mozglue
instead of mfbt. Except logalloc/replay, which cherry-picks what it
uses.
Differential Revision: https://phabricator.services.mozilla.com/D103730
The current implementation is a regression on microbenchmarks that
reallocate allocations that go over gPageSize * 32 compared to memcpy().
Differential Revision: https://phabricator.services.mozilla.com/D100217
In clang-cl builds, thanks to clang-cl's defining of `_MSC_VER`, this function was not marked `noexcept`. This led clang to believe that it could call `arena_t`'s constructor without checking for null.
I suppose we could scope the condition down to real MSVC, but since we don't support that anymore, we can just stop checking.
Differential Revision: https://phabricator.services.mozilla.com/D99137
While all toolkit and js-based projects make use of mfbt, some others,
like tools/crashreporter and tools/update-packaging, don't.
So instead of including mfbt from the top-level directory, include it
from the relevant project top-level mozbuilds.
This allows to remove the dependency on mfbt files in the hash for the
minidump-stackwalk and mar-tools toolchains.
Differential Revision: https://phabricator.services.mozilla.com/D98378
Sheriff note: We should keep this regardless of whether bug 1675600 sticks.
The comment above SmokeDMD's `RunTests()` says "This test relies on the compiler not doing various optimizations ... So we compile it with -O0 (or equivalent)".
That suggests that LTO should also be disallowed.
Differential Revision: https://phabricator.services.mozilla.com/D97336
Due to lack of `CXX_TYPE`, clang-cl builds were accidentally taking the `else` branch where the `-O0` was ignored/unrecognized. This went unnoticed for a long time until it busted the landing of bug 1677726.
While here, fix the intent of SmokeDMD: `-Og-` is a silent no-op in clang-cl, so it's not actually disabling anything.
Differential Revision: https://phabricator.services.mozilla.com/D97387