This way we don't have to go through a bunch of printf nonsense, and we
ought to be able to arrive at optimized routines that take advantage of
constant radices, etc.
Differential Revision: https://phabricator.services.mozilla.com/D25141
--HG--
extra : moz-landing-system : lando
Due to coming changes involving the IOInterposer, the WindowsDllInterceptor may be set up later than the sandbox. The sandbox hooks some of the same functions, so the Interceptor is running into its hooks instead of the original implementations it anticipated. This patch allows it to recognize and efficiently patch those hooks when that happens.
Differential Revision: https://phabricator.services.mozilla.com/D24654
--HG--
extra : moz-landing-system : lando
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : source : 0615c775a0cf6e8f98e1c051cd574c0d602a738a
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : moz-landing-system : lando
In the tree we have two copies of printf_stderr() with the comment,
"Ideally this should be shared". This moves the function to a new exported
header which can be the basis for other similar debugging utility functions.
To include it,
#include "mozilla/glue/Debug.h"
A small concern with this is that printf_stderr() is in the global namespace,
and could conflict if it's inadvertently included along with, for example,
nsDebug.h which also defines this function. The warning in the comment at the
top of the file attempts to mitigate this.
Differential Revision: https://phabricator.services.mozilla.com/D13196
--HG--
extra : moz-landing-system : lando
BasicDllServices is used to gain access to the authenticode APIs in non-Gecko
contexts. One feature that WinDllServices provides is the ability to register
a callback interface to be notified when a DLL has been loaded.
This is not particularly useful in the BasicDllServices use case, and in the
"handle a launcher process failure on a background thread" use case, would
actually be harmful.
This patch modifies the DLLServices backend to offer a "basic" option that
omits the callback stuff.
Differential Revision: https://phabricator.services.mozilla.com/D19696
--HG--
extra : moz-landing-system : lando
This patch doesn't cover all possible functions for which we currently
instantiate interceptors inside Firefox/Gecko. Rather than asserting, we just
fail in those cases (at least until we have full coverage of existing uses).
This is okay, as for the upcoming milestone 2 of aarch64 builds, we are most
concerned with successfully being able to hook the following functions:
ntdll!LdrLoadDll
ntdll!LdrUnloadDll
ntdll!LdrResolveDelayLoadedAPI
user32!GetWindowInfo
So, within that context, the aarch64 implementation is fairly simple:
Each instruction is 4-bytes wide. We iterate down each instruction, and if the
current instruction is *not* PC-relative, we just copy it verbatim. If we
encounter an instruction that *is* PC-relative, we either decode it and
rewrite it inside the trampoline, or we fail. For the purposes of milestone 2,
the only instruction that is essential to decode is ADRP.
In bug 1526016 I modify TestDllInterceptor to exclude functions that are not
yet supported by this patch.
Differential Revision: https://phabricator.services.mozilla.com/D19446
--HG--
extra : moz-landing-system : lando
FramePointerStackWalk can trip ASAN when walking the stack and reading outside
of ASAN-protected objects.
Differential Revision: https://phabricator.services.mozilla.com/D20208
--HG--
extra : moz-landing-system : lando
The actual subcategories will be added in later patches, so that there are no
unused categories.
Differential Revision: https://phabricator.services.mozilla.com/D11334
--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
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch measures the duration of module loads and passes it up to
UntrustedModulesManager where, in later patches, it will be consumed by
telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D16011
--HG--
extra : moz-landing-system : lando
WindowsDllBlocklist installs a callback function that fires whenever a DLL
is loaded. The installer function shares an SRWLock with the callback
function.
SRWLock is not re-entrant, so if the installer function accidently causes a
DLL load before releasing the lock, the callback function will deadlock.
This occured trying to solve Bug 1402282, where the installer function used
"new" to allocate memory, which called the Win32 "RtlGenRandom()" function,
which loaded bcrypt.dll, which caused the callback to fire off, which tried
to lock the mutex that was already locked by the installer function.
Hopefully this will save another developer lots of debug time in the future by
turning a difficult-to-debug deadlock into a nice, loud assertion.
Differential Revision: https://phabricator.services.mozilla.com/D15840
--HG--
extra : moz-landing-system : lando
It's a define that needs winuser.rh to be included.
MozReview-Commit-ID: LPfJOwnNm6V
Differential Revision: https://phabricator.services.mozilla.com/D15333
--HG--
extra : moz-landing-system : lando
mozilla::PrintfTarget::cvt_f release asserts that the desired printf
fit into a statically-sized buffer. However, this may not be the case
if the user requested a larger width or precision. Handle this
unusual case by allocating a temporary buffer.
MozReview-Commit-ID: 2WicecHDzDR
Differential Revision: https://phabricator.services.mozilla.com/D15989
--HG--
extra : moz-landing-system : lando
Chromium IPC locks have this and the API gets used, so we need to expose
it ourselves if we're going to use our locks in place of the Chromium
IPC locks. This patch changes the mozglue parts; tweaking the xpcom
parts is the next patch.
In Windows 7 x64, GetFileAttributesW begins with a short, backwards jump that can't safely be converted by the interceptor. Additionally, the function doesn't have enough NOP space after the JMP for the trampoline. However, the target of the short JMP is a long JMP, followed by plenty of NOP space. This patch moves the trampoline location from the first JMP to the second.
Differential Revision: https://phabricator.services.mozilla.com/D11258
--HG--
extra : moz-landing-system : lando
Nightly is reporting mozglue.dll as being untrusted in the untrusted modules
ping. Until now, xpcshell tests hard-code mozglue to appear as untrusted in
order to cover certain code paths related to startup modules.
This patch:
1. Checks explicitly for the xpcshell environment and only applies this logic
during xpcshell tests.
2. Uses a purpose-build DLL, "untrusted-startup-test-dll.dll", instead of
mozglue. This is more explicit and doesn't interfere with any "true"
processing of mozglue.
Differential Revision: https://phabricator.services.mozilla.com/D14720
--HG--
extra : moz-landing-system : lando
As far as my stepping through WalkStackMain64 goes, it seems StackWalk64
doesn't work, even with more information added to the frame data it's
given.
Switching to the same code as for x86-64, however, works, albeit
skipping too many frames, but all platforms are actually skipping too
many frames, so let's ignore that for now and leave it to bug 1515229.
Differential Revision: https://phabricator.services.mozilla.com/D14929
--HG--
extra : moz-landing-system : lando
- modify line wrap up to 80 chars; (tw=80)
- modify size of tab to 2 chars everywhere; (sts=2, sw=2)
--HG--
extra : rebase_source : 7eedce0311b340c9a5a1265dc42d3121cc0f32a0
extra : amend_source : 9cb4ffdd5005f5c4c14172390dd00b04b2066cd7
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13371
--HG--
extra : moz-landing-system : lando
This also uses idiomatic packaging of the native libraries, which
will allow easier downstream consumption of GeckoView.
Differential Revision: https://phabricator.services.mozilla.com/D10775
--HG--
extra : moz-landing-system : lando
Cameron McCormack
Nathan Froyd
David Parks
John Lin
Karl Tomlinson
Mike Shal
Noemi Erli
Sylvestre Ledru
Carl Corcoran
Ryan Hunt
Aaron Klotz
Cosmin Sabou
Masatoshi Kimura
Gerald Squelart
Markus Stange
Mike Hommey
Dorel Luca
Eric Rahm
Tom Ritter
Ehsan Akhgari
David Major
Gabriele Svelto
Chris Martin
Coroiu Cristina
Jacek Caban
shindli
Tom Tromey
Tooru Fujisawa
Benjamin Bouvier
Honza Bambas
James Willcox