As per mozglue/static/README:
> mozglue/static contains parts of the mozglue library that can/should be
> statically linked to e.g. js/Gecko.
The compression part of MFBT is a good candidate for this.
Differential Revision: https://phabricator.services.mozilla.com/D221565
This patch adjusts the various places where we initialize content
processes to call SetGeckoProcessType as early as possible, and be more
consistent. After this change we should only ever set GeckoProcessType
and GeckoChildID once per-process (with the exception of the fork server
process).
In addition to this validation, some more checks around the fork server
were added, such as to prevent forking another forkserver, or forking a
non-content process.
As part of this change, there was some refactoring/cleanup done, such as
removing plugin-container.cpp and content_process_main, as compared to
the other duplicated code between the two call-sites, the duplication
was relatively small, and inlining it helped make things more readable.
Differential Revision: https://phabricator.services.mozilla.com/D218471
This requires quite a bit of piping to get the ChildID passed everywhere where
we currently pass the pid in IPC. This is done by adding a new struct type
(EndpointProcInfo), which is passed around instead of OtherPid in these places,
and contains the full pid.
In most cases, it was a fairly painless change to move over, however in some
cases, more complex changes were required, as the pid was being stored
previously in something like an Atomic<...>, and needed to be switched to using
a mutex-protected value.
In the future, it may be possible to remove OtherPid from IPDL actors once
everything is migrated to ChildID, but we're still a long way off from that, so
for now we unfortunately need to pass both around.
Differential Revision: https://phabricator.services.mozilla.com/D217118
The new GeckoChildID type introduced in this patch is inspired by the existing
ContentParentID type used by ContentParent, but is currently distinct. It is
supported by all process types at the GeckoChildProcessHost level and can be
read for the current process from anywhere.
As this type is similar in many ways to the process type, and should be
available as early as possible within child processes, this was added alongside
the GeckoProcessType value within mozglue to make that easier to do.
The type was chosen to be an int32_t to make it feel similar to a PID, which we
currently use for process identity comparisons across the codebase. The
intention is for GeckoChildID to be preferred for these within-gecko checks, as
these IDs will not be re-used and can be known earlier during child process
creation.
Differential Revision: https://phabricator.services.mozilla.com/D217117
The previous patchset failed to properly convert the RECT to be cleared
from screen- to window-coordinates. (This wasn't noticed because the two
only differ when nontrivial chrome such as the titlebar is present,
which by default it's not.)
Differential Revision: https://phabricator.services.mozilla.com/D214334
When creating the skeleton UI window, cloak and clear it to a theme-
appropriate color before first showing it, just as is done in nsWindow.
Differential Revision: https://phabricator.services.mozilla.com/D212764
The sanitization function for URL and FilePath cannot currently sanitize
an arbitrary string in the profiler data. The expectation is that the URL
starts with a scheme like http:// and that a file path contains a /,
so none of them are sanitized if the contents are a domain name.
This commit introduces a new 'sanitized-string' format, that the profiler
can make sure to completely blank out.
Differential Revision: https://phabricator.services.mozilla.com/D211171
This patch introduces an aInstructionFilter argument to
CollectModuleSingleStepData to allow filtering which kind of
instructions should be recorded. We implement the All default filter and
the CallRet filter.
Differential Revision: https://phabricator.services.mozilla.com/D211196
This patch makes the single-step data collection code that we
implemented for bug 1571516 reusable, while preserving its behavior.
No functional changes, except for a slight reordering of the
error-result enum.
We define a generic CollectSingleStepData function that embeds the
magic for starting to trigger single step exceptions and for acting upon
them.
We define a more specialized CollectModuleSingleStepData function which
can be reused if the purpose of single step data collection is to
monitor what paths are taken within a specific module. It stores the
collected data in stack, so that it can be accessed from crash reports.
This code is considered unstable and thus only available in Nightly and
early Beta and only used on paths that are known to crash already.
Differential Revision: https://phabricator.services.mozilla.com/D211195
We have put the profilerOverhead recording behind a environment variable in
Bug 1726657 but apparently we still kept outputting some things in the JSON
output and also iterating the buffer to find profilerOverhead entries. Let's
skip this if this env variable is not set.
Differential Revision: https://phabricator.services.mozilla.com/D210469
Rustc/Cargo 1.80 introduces checks for uses of cfg() and features.
oom_with_hook and oom_with_alloc_error_panic are not meant to be
externally-enabled features, so they're better turned into cfg(),
which also now requires additional setup.
Differential Revision: https://phabricator.services.mozilla.com/D210588
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
The -ldl flag was previously set globally, it's now set for the libs
that use it.
Also rationalize the difference between HAVE_DLOPEN and HAVE_DLFCN_H.
Differential Revision: https://phabricator.services.mozilla.com/D203594
Whatever issues there were with detect_stack_use_after_return during the
clang trunk cycle for clang 15 seem to be gone.
On the other hand, changes in clang 18 trigger a bug[1] that causes stack
misalignment in AVX-512 code when detect_stack_use_after_return is
disabled.
1. https://github.com/llvm/llvm-project/issues/91565
Differential Revision: https://phabricator.services.mozilla.com/D209907
Whatever issues there were with detect_stack_use_after_return during the
clang trunk cycle for clang 15 seem to be gone.
On the other hand, changes in clang 18 trigger a bug[1] that causes stack
misalignment in AVX-512 code when detect_stack_use_after_return is
disabled.
1. https://github.com/llvm/llvm-project/issues/91565
Differential Revision: https://phabricator.services.mozilla.com/D209907
Mike Hommey
Nicolas Guichard
Florian Quèze
Matthew Gaudet
Iulian Moraru
Nika Layzell
c8ef
Sylvestre Ledru
Ray Kraesig
Jed Davis
Nazım Can Altınova
Alexandre Lissy
alwu
Valentin Gosu
Yannis Juglaret
Patrycja Rosa
Cristina Horotan
Ryan VanderMeulen
Julien Cristau
serge-sans-paille
Tamas Szentpeteri
acseh
Cristian Tuns
Emilio Cobos Álvarez