This allows for individual Marker Types to specify that they wish to have the names passed in profiler_add_marker stored as a field in ETW. This also converts simple marker types to use this in order to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D203983
This allows for individual Marker Types to specify that they wish to have the names passed in profiler_add_marker stored as a field in ETW. This also converts simple marker types to use this in order to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D203983
This commit modifies ProfilingFrameIter to be able to report which tier of
wasm execution a function is in, then uses that in the profiler to report
more fine-grained categories for wasm code.
Differential Revision: https://phabricator.services.mozilla.com/D201020
This patch makes several fundamental changes to the logic we use to inform
the main process whenever the WER runtime exception module intercepts a child
process crash:
* We no longer read the process type or any other data from the child process;
the process type is passed as the runtime exception module's context
* We no longer read the address of the memory area used to communicate with the
main process from the child process arguments. Instead we allocate memory
directly into the main process and store the required information there
* We don't read anything from the main process either, the pointer to the
function used to notify the main process is now found by looking out its
dedicated section in the parent process' xul.dll mapping
* We no longer read the OOM crash annotation from a child process, this
functionality will be restored by making the module use the mozannotation
crates to fetch all the annotations
Differential Revision: https://phabricator.services.mozilla.com/D201589
On Linux and Android, both jitdump and the marker file will keep using
`CLOCK_MONOTONIC` nanoseconds, as before.
On macOS, both jitdump and the marker file will now be using
`TimeStamp::RawMachAbsoluteTimeNanoseconds()` , i.e. "nanoseconds since
mach_absolute_time origin".
This value has the advantage that it is also relatively easy to obtain
in other browser engines, because their internal timestamp value is stored
in milliseconds or nanoseconds rather than in `mach_absolute_time` ticks.
In the past, on macOS, Firefox was using `CLOCK_MONOTONIC` nanoseconds for
jitdump and `TimeStamp::RawMachAbsoluteTimeValue()` for the marker file.
This inconsistency is now fixed.
I will update samply to change how it treats jitdump timestamps on macOS.
There are no other consumers of jitdump files on macOS that I know of.
On Windows, we will keep using raw QPC values for the marker file - this
matches what's in the ETW events. Jitdump on Windows is mostly unused but
I'm updating it to match.
Furthermore, this fixes the order in mozglue/misc/moz.build to make sure
we always use the TimeStamp_darwin implementation on Darwin (and not just
due to a broken configure check, see bug 1681445), and it fixes the #ifdef
in TimeStamp.h to match the Darwin check.
Differential Revision: https://phabricator.services.mozilla.com/D199592
This patch defines shared-libraries.h header file all the time even when the
MOZ_GECKO_PROFILER is not defined. `SharedLibraryInfo` class now has
stubbed-out implementation-specific methods that are defined in platform
specific cpp files. This allows us to always define the header file which
will let us remove a lot of ifdefs in the following patch.
Differential Revision: https://phabricator.services.mozilla.com/D199361
We used to rely on our linker being able to decompress zlib streams
directly to memory, but that hasn't been the case for very long.
Differential Revision: https://phabricator.services.mozilla.com/D198912
We used to rely on our linker extracting the libraries to disk before
loading them in memory. This hasn't been the case since bug 1486524.
Differential Revision: https://phabricator.services.mozilla.com/D198911
There is no need to build Zip.cpp anymore when the linker is not
enabled, because nsGeckoUtils.cpp doesn't actually use it anymore.
Differential Revision: https://phabricator.services.mozilla.com/D198349
`mach` requires Python 3.7+ since bug 1734402, and Python 3.7 made preserving
dictionary insertion order an official part of the language.
Also use `safe_load` instead of `load` because it doesn't require a loader argument
and is safer (although it doesn't really matter for this use case).
Differential Revision: https://phabricator.services.mozilla.com/D197497
This adds code to emit ETW markers on windows. It supports all current
markers through a generic marker emitting schema. It also supports
additional payload and filtering for any markers that are updated to a
new compile-time marker schema system. Because of our abstraction layer
and cross-platform nature we have to manually create the TraceLogging
structs used and can't rely on their macro's, but this should give us a
very flexible and performant marker implementation on ETW.
Differential Revision: https://phabricator.services.mozilla.com/D196331
EnsureDbgHelpInitialized() and EnsureSymInitialized() can currently
cause deadlocks through reentrancy in DEBUG and FUZZING builds, through
MOZ_ASSERT and MOZ_CRASH failures. This patch merges these functions
into a single InitializeDbgHelp() reentrancy-safe function.
Differential Revision: https://phabricator.services.mozilla.com/D196421
In the fx codebase, we tend to use __attribute__((naked)) for plain
assembly functions with a C interface. Instrumenting these functions can
mess up this assembly, so we conservatively also want to prevent
instrumentation.
Differential Revision: https://phabricator.services.mozilla.com/D196154
Otherwise injected code, under temporal profiling, messes up the inline
assembly used by the wrapper. Ideally, we would use extended asm to
correctly state the constraint, but it is incompatible with naked
functions.
See discussion in https://github.com/llvm/llvm-project/issues/74573 for
the interaction between ``naked`` and profiling.
Differential Revision: https://phabricator.services.mozilla.com/D195315
In order to investigate LoadLibraryW failures in bug 1851889, we make
LoadLibraryOrCrash collect ntdll.dll single step data in utility
processes. The data will be available in the stack of the crashing
thread in nightly and early beta builds.
Single-step data collection only occurs after a first failure to load
the library, when we would be about to crash anyway. This ensures that
the patch cannot introduce extra unstability to LoadLibraryOrCrash.
Single-stepping through all ntdll instructions would record too many
steps, so we add the capability to record only call and ret
instructions. We apply this new capability for the single-step recording
of LoadLibraryW. Thanks to the detection of error state changes, this
should help us identify what path leads to a 0x241 last error in
bug 1851889.
Depends on D194203
Differential Revision: https://phabricator.services.mozilla.com/D194204
Bas Schouten
Sandor Molnar
Mike Hommey
Ryan Hunt
Emilio Cobos Álvarez
Narcis Beleuzu
Artur Iunusov
Gabriele Svelto
Kelsey Gilbert
Markus Stange
Nazım Can Altınova
Botond Ballo
Steve Fink
Stanca Serban
Florian Quèze
Jan de Mooij
Yannis Juglaret
serge-sans-paille
Logan Rosen
Yury Delendik
Cristian Tuns