As the aarch64 instruction emitters do not return the BufferOffset of
the access instruction, we have to resort to AutoForbidPools to keep
the metadata emitted at the correct address of the access. Manual
inspection of the assembler code and the addressing modes used reveals
that this is viable, if it's done just so.
I've added comments to highlight the fact that it is a little brittle,
and the AutoForbidPools with an instruction window of 1 instruction
will cause failures if assumptions about the machine code should be
violated accidentally in the future.
--HG--
extra : rebase_source : 892744f1b16e970243ca2b2a11fa476b192cf615
extra : amend_source : e7d33696d0f02a48592d8a73f7eaafa32d443656
Entry storage allocation now occurs on the first lookupForAdd()/put()/putNew().
This removes the need for init() and initialized(), and matches how
PLDHashTable/nsTHashtable work. It also removes the need for init() functions
in a lot of types that are built on top of mozilla::Hash{Map,Set}.
Pros:
- No need for init() calls and subsequent checks.
- No memory allocated for empty tables, which are not that uncommon.
Cons:
- An extra branch in lookup() and lookupForAdd(), but not in put()/putNew(),
because the existing checkOverloaded() can handle it.
Specifics:
- Construction now can take a length parameter.
- init() is removed. Explicit length-setting, when necessary, now occurs in the
constructors.
- initialized() is removed.
- capacity() now returns zero when the entry storage is absent.
- lookupForAdd() is no longer `const`, because it can instantiate the storage,
which requires modifications.
- lookupForAdd() can now return an invalid AddPtr in two cases:
- old: hashing failure (due to OOM in the hasher)
- new: OOM while instantiating entry storage
The existing failure handling paths for the old case work for the new case.
- clear(), finish(), and clearAndShrink() are replaced by clear(), compact(),
and reserve(). The old compactIfUnderloaded() is also removed.
- Capacity computation code is now in its own functions, bestCapacity() and
hashShift(). setTableSizeLog2() is removed.
- uint32_t is used throughout for capacities, instead of size_t, for
consistency with other similar values.
- changeTableSize() now takes a capacity instead of a deltaLog2, and it can now
handle !mTable.
Measurements:
- Total source code size is reduced by over 900 lines. Also, lots of existing
lines got shorter (i.e. two checks were reduced to one).
- Executable size barely changed, down by 2 KiB on Linux64. The extra branches
are compensated for by the lack of init() calls.
- Speed changed negligibly. The instruction count for Bench_Cpp_MozHash
increased from 2.84 billion to 2.89 billion but any execution time change was
well below noise.
With asm.js atomics gone and wasm atomics opting in to standard
trap-based OOB handling, we should never fail to find a trap site. So
assert that we always find it, and remove code that is now dead.
--HG--
extra : rebase_source : 5ae030ab9ac92f48d84328c7ed5048ced299eb20
extra : source : 7dc12de9bf40160f8809bbe4fc16f4b54f6e5fa6
extra : histedit_source : 240aef6bd1195f13789d4da8d28a6698bc3dbbff
A large and mostly mechanical change: Prune the non-JS atomic APIs in
MacroAssembler.h and add many wasm-specific APIs instead.
The three non-JS APIs that remain in MacroAssembler.h could also be
removed but are used in multiple places to implement the JS APIs, and
it seemed fine to just leave them in. They are after all generally
useful.
Note, this patch changes MIPS code so that it compiles, but it does
not insert the necessary emitting of metadata, partly because the
mechanics of that for 64-bit ops on 32-bit systems depends on the
implementation of those 64-bit ops, and partly because I am happy to
let the MIPS maintainers do the work and check it. I have left behind
FIXME comments where changes are needed.
The one additional test case in jit-test is a result of closely
reading existing code and finding a bug that should have caused a
failure, but didn't, once the wasm/asm.js fallback for signal handling
was removed.
--HG--
extra : rebase_source : 4958997adb6050222bcde609dca6d00108c0a8f9
extra : histedit_source : b7fbcf868c60d7079d7827d98c7e7aad2d7d1f32
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
Three interlocking changes here:
- when accessing an unaligned word, access bytes in high-to-low order
- emit metadata for the first (highest) byte accessed
- when accessing a multi-word item (i64, f64), access the highest
addressed word first
Most of these changes are straightforward. In a couple of cases I
un-nested tangled control flows by breaking things into cases; this
leads to a little duplicated code but is IMO much easier to follow.
--HG--
extra : rebase_source : cd3b856b60b22c9e153452e984feeadc64103f25
This is also better security-wise: if we're writing the structured clone in some compartment that shouldn't have access to the underlying data of the ImageData, we shouldn't be giving that access here.
This refactors gc::Cell derived types to start with a uintptr_t-sized
field with the low bits reserved for the GC and uses these bits for
relocation mechanism.
- JSString now stores flags in a uintptr_t. On 32-bit platforms, a
second field is used to hold length.
- Redefine JSString flag bit positions to avoid cell reserved bits.
- Forwarded Cells are now indicated by a reserved flag instead of a
magic invalid-pointer-like value.
- gc::RelocationOverlay now extends gc::Cell
- Update js::Symbol, js::Scope and js::BigInt fields to be compatible.
MozReview-Commit-ID: Cs5OavbHmqK
Add accessor methods so that underlying storage strategy can be changed
later. This patch should not change current behaviour.
MozReview-Commit-ID: IRA53TQShe6
This gcc 4.8.5 workaround (from bug 1316850) is no longer needed because Firefox currently requires gcc 6.1 or later (as of bug 1444274).
MozReview-Commit-ID: 4JFmOYoJnMH
--HG--
extra : rebase_source : f348a629f25f6852250306d969262372460a677a
extra : source : cb42b2192694148ffdf97c3a5c2fabb2578a0ec0
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : 1702e63fed719fc92def2bdbbb8a7c53572432db
extra : source : 41bedc526dd6ec6b7e8c7be1c832ac60c81d6263
Because XrayTraits::attachExpandoObject operates in the Xray target realm/compartment and we cannot use the Xray wrapper with JSAutoRealm, we pass the caller's global as exclusiveWrapperGlobal and use that.
This also changes XrayWrapper<Base, Traits>::defineProperty to call ensureExpandoObject in the wrapper (instead of target) realm. This didn't matter before, because ensureExpandoObject immediately entered the target realm anyway.
Because getOwnPropertyFromTargetIfSafe operates in the Xray target realm/compartment and we cannot use the Xray wrapper with JSAutoRealm, we pass the caller's global as wrapperGlobal and use that.
* Introduce a setZone method that changes the zone and the freelist.
* leaveAtomsZone() private
--HG--
extra : rebase_source : 1da68a20211b410b651a4d12548f09b3b942b017
Right now, a lot of test code relies on side-effects of SpecialPowers being
loaded into frame script globals. In particular:
- It forces permissive COWs from those scopes, which allows frame scripts to
pass objects from those scopes to unprivileged content that they otherwise
wouldn't.
- It imports a bunch of helper modules and WebIDL globals which would
otherwise not be available.
Fortunately, this seems to only impact test code at this point. But there's a
real down-the-road risk of it impacting shipping code, which ends up working
in automation due to the side-effects of SpecialPowers, but failing in real
world use.
MozReview-Commit-ID: G27eSSOHymX
--HG--
extra : rebase_source : c528dffe3a54eec75ad6cb358980b783b00eb4a4
The problem we're solving here: getting/entering the realm/global of a cross-compartment wrapper doesn't make sense once there are multiple realms in a compartment and the CCW will be shared by all of them. Because nsXPCWrappedJS can store a CCW, we will no longer be able to use this JSObject to enter the target realm.
What this patch does: we pass a JSContext* to nsXPCWrappedJS::GetNewOrUsed and we use this to store a global object in nsXPCWrappedJS (with the invariant that the object and global stored in nsXPCWrappedJS are same-compartment). Then when we want to enter the nsXPCWrappedJS's target realm, we use this global object instead of the maybe-CCW object. Because we currently still have one realm per compartment and the objects are same-compartment, this is guaranteed to preserve behavior for now.
nsXPCWrappedJS has some code to deal with weak pointers. Fortunately this applies only to root wrappers and root wrappers always store an unwrapped JSObject, so the extra global we store is guaranteed to be marked by the GC in that case (a global object is never collected when there are live JSObjects belonging to the same realm).
Because it's quite strange, badly named, not that useful, and barely used.
Also remove WeakMap::lookupWithDefault(), which is similar, but not used at
all.
MozReview-Commit-ID: IhIl4hQ73U1
--HG--
extra : rebase_source : 7da237a56391836ca5d056248f18bd5e2d8b1564
Because (a) it's kinda weird, and (b) only used in a single test, where it can
be easily replaced with a vanilla add().
MozReview-Commit-ID: L4RoxFb7yGG
--HG--
extra : rebase_source : 515a5ede5d417686907345ad9069c6a41669dd17
It's identical to mozilla::CStringHasher.
Also fix a comment at the top of HashTable.h about CStringHasher.
--HG--
extra : rebase_source : 92176c4f6ea8041f309764b4ce0271a494853a7b
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : b4f0d4bf83c64851028c271d3fab3ebcb6fbcd3e
Summary:
DestructValue acts a lot like CleanupValue, however in addition to normal
cleanup work, it invokes the destructor of complex data types. This is important
to ensure that constructors and destructors are matched for these complex data
types.
CleanupValue is also used to clean up a value without destructing it, so cannot
be modified in-place.
Depends On D2689
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2690
Summary:
This macro simplifies code which allows performing an operation on or
extracting information from a particular nsXPTType's native representation.
It is also used in part 2 to implement xpc::DestructValue.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1480624
Differential Revision: https://phabricator.services.mozilla.com/D2689
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant functions are updated to take a typed enum (in C++) and an
integer constant (in JavaScript). A JavaScript wrapper around the crash
reporter service is provided to hold the constants. The existing whitelists
and blacklists of annotations are also generated from the YAML file and the
existing duplicate code has been consolidated. Once written out to the .extra
file the annotations are converted in string form and are no different than
the existing ones.
All existing annotations have been included (and some obsolete ones removed)
and all call sites have been updated including tests.
--HG--
extra : rebase_source : f0e8d229581ac5c0daa0e0454cb258746108e28d
Matthew Gaudet
Tooru Fujisawa
Jon Coppeard
Lars T Hansen
Nicholas Nethercote
Jan de Mooij
André Bargull
Boris Zbarsky
Benjamin Bouvier
Gabriele Svelto
Jim Blandy
Ted Campbell
Daniel Varga
Mike Hommey
Nathan Froyd
Chris Peterson
Brindusan Cristian
Kris Maglione
Luke Wagner
Bogdan Tara
Paul Bone
agashlin@mozilla.com
Logan F Smyth
arthur.iakab
Ms2ger
Jan-Ivar Bruaroey
Masatoshi Kimura
Narcis Beleuzu
Sebastian Hengst
Brian Hackett
Noemi Erli
Dorel Luca
Nika Layzell
Coroiu Cristina