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
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
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
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 patch adds support on x64 for 10-byte detour patches in certain cases.
In particular, the reserved region of trampoline memory must be allocated
within the bottommost 2GB of the address space.
This feature is currently only activated when detouring functions exported by
ntdll.dll.
Differential Revision: https://phabricator.services.mozilla.com/D10285
--HG--
extra : moz-landing-system : lando
This patch adds support on x64 for 10-byte detour patches in certain cases.
In particular, the reserved region of trampoline memory must be allocated
within the bottommost 2GB of the address space.
This feature is currently only activated when detouring functions exported by
ntdll.dll.
Differential Revision: https://phabricator.services.mozilla.com/D10285
--HG--
extra : moz-landing-system : lando
This patch adds support on x64 for 10-byte detour patches in certain cases.
In particular, the reserved region of trampoline memory must be allocated
within the bottommost 2GB of the address space.
This feature is currently only activated when detouring functions exported by
ntdll.dll.
Differential Revision: https://phabricator.services.mozilla.com/D10285
--HG--
extra : moz-landing-system : lando
They were not displayed in the UI, and the instructions to initialize the line
field of a stack frame increased code size unnecessarily.
This change reduces the binary size on Linux x64 by around 100KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build:
@@ -20,17 +20,16 @@
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
movq %rdx, (%rax,%rcx)
movq $0x0, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x106, 0x18(%rax,%rcx)
movl $0x1c, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
Depends on D9193
Differential Revision: https://phabricator.services.mozilla.com/D9195
--HG--
extra : moz-landing-system : lando
They were not displayed in the UI, and the instructions to initialize the line
field of a stack frame increased code size unnecessarily.
This change reduces the binary size on Linux x64 by around 100KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build:
@@ -20,17 +20,16 @@
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
movq %rdx, (%rax,%rcx)
movq $0x0, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x106, 0x18(%rax,%rcx)
movl $0x1c, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
Depends on D9193
Differential Revision: https://phabricator.services.mozilla.com/D9195
--HG--
extra : moz-landing-system : lando
They were not displayed in the UI, and the instructions to initialize the line
field of a stack frame increased code size unnecessarily.
This change reduces the binary size on Linux x64 by around 100KB.
Here's a diff of the impact on the code generated for Attr_Binding::get_specified
in the Mac build:
@@ -20,17 +20,16 @@
movq 0x8(%rbx), %rax
movq %r12, %rcx
shlq $0x5, %rcx
leaq aGetAttrspecifi, %rdx ; "get Attr.specified"
movq %rdx, (%rax,%rcx)
movq $0x0, 0x8(%rax,%rcx)
leaq -40(%rbp), %rdx
movq %rdx, 0x10(%rax,%rcx)
- movl $0x106, 0x18(%rax,%rcx)
movl $0x1c, 0x1c(%rax,%rcx)
leal 0x1(%r12), %eax
movl %eax, 0x10(%rbx)
movq %r15, %rdi
call __ZNK7mozilla3dom4Attr9SpecifiedEv ; mozilla::dom::Attr::Specified() const
movzxl %al, %eax
movabsq $0xfff9000000000000, %rcx
Depends on D9193
Differential Revision: https://phabricator.services.mozilla.com/D9195
--HG--
extra : moz-landing-system : lando
This patch adds a new static member to the TimeStamp class to store the
current locked *time* (in ms since the epoch) in addition to the current locked
timestamp.
We point the JS Engine at this value if Fuzzyfox is enabled.
Creates GetFuzzyfoxEnabled() functions that check a static boolean.
Exposes SetFuzzyfoxEnabled() because we cannot depend on Pref
Observation code inside the TimeStamp class.
TimeStamp::Now will now return a Fuzzy value.
We add a NowReally function to support obtaining the real timestamp.
We also add a UsedCanonicalNow to expose whether the TimeStamp was real or fuzzy.
Creates a FuzzyFox class for implementating the core of the step/sleep
algorithm. Starts it in nsLayoutStatics::Initialize()
Adds the fuzzyfox prefs.
Moves the ms2mt macros from TimeStamp_windows.cpp to TimeStamp_windows.h
and creates a new public function GetQueryPerformanceFrequencyPerSec() to
expose a static variable in the .cpp file. This is necessary to support
the macros being usable anywhere. (And we use the macros in FuzzyFox.)
This code throws an error in clang on the inner MMPolicy:
error: declaration of 'MMPolicy' shadows template parameter
Notethat the template parameter is declared earlier at the
class definition of ReadOnlyTargetFunction
MozReview-Commit-ID: buLE9d22YS
Differential Revision: https://phabricator.services.mozilla.com/D4571
--HG--
extra : moz-landing-system : lando
This code is untested and has been cargo-culted a little bit from the
existing x86 code, but should work OK; all the code in Windows is
compiled with frame pointers, we're compiled with frame pointers after
the previous patch, and so the frame pointer unwinding path makes the
most sense.