Otherwise, LTO will eliminate it because the compiler can't see the
calls to PrepareAndDispatch from the relevant assembly file.
Differential Revision: https://phabricator.services.mozilla.com/D26244
--HG--
extra : moz-landing-system : lando
ARM's xptcstubs use a slightly different setup for PrepareAndDispatch
than...well, all of our other stubs. This difference appears to be
causing problems with LTO builds. Change the setup to be more like our
other stubs, which additionally gets rid of some of the `asm` nonsense.
Differential Revision: https://phabricator.services.mozilla.com/D26243
--HG--
extra : moz-landing-system : lando
We need to preprocess these files so we can eventually add unwind
information, for which we need to include C headers.
Differential Revision: https://phabricator.services.mozilla.com/D19819
--HG--
extra : moz-landing-system : lando
Currently the [ref] and [ptr] types share the same underlying
implementation. This is unfortunate, and can cause correctness problems
with outparam refs (as an example).
By using the same tools used to allow other larger objects (such as
jsid, nsTArray, and nsString) to be stored directly in the nsXPTCVariant
object, this patch directly stores the nsID in the nsXPTCVariant object
when calling from JS into C++.
Using this new strategy avoids an nsID* allocation every time we pass
one over XPConnect, and should also allow us to simplify callers.
In addition, some special casing is added to xpidl to make it possible
to use the nsid reference type objects directly inside of Array<T>,
which will allow us to remove `[array] nsIIDPtr` callers.
Differential Revision: https://phabricator.services.mozilla.com/D19175
--HG--
extra : moz-landing-system : lando
Gecko Profiler uses DWARF information to get stack. But xptcall assembler for
Android/aarch64 doesn't have CFI directive, so it cannot walk stack well.
Differential Revision: https://phabricator.services.mozilla.com/D18335
--HG--
extra : moz-landing-system : lando
As in Bug 1390583 and Bug 1470993, this will correct them to be external symbols
Differential Revision: https://phabricator.services.mozilla.com/D6044
--HG--
extra : moz-landing-system : lando
Since the ABI on this platform just uses the ARM procedure call
standard, which is the same standard Unix uses, we can just
copy-and-paste everything, with some adjustments to the assembly code to
compile properly.
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
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
This will get us both more clarity as to what types are, but also will improve switch exhaustiveness checks.
Summary: Depends On D2113
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2114
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
A goal of the Sequence<T> work is to allow using more complex types within lists
in XPConnect. For example, we ideally want to support `Sequence<AString>`,
rather than requiring people to use the unergonomic 'wstring' type.
These types require initialization before they can be read into. Currently this
initialization for parameters is directly handled by XPCWrappedNative's
CallMethodHelper object.
This patch introduces a new function to the `xpc` namespace to initialize a
specific value from an uninitialized state to a safe state.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2105
Summary:
This more closely matches the C++ names, and reflects the fact that the
reflected type is not WebIDL's mozilla::dom::Sequence. The reasoning behind this
type difference is for ergonomics, due to xpidl only being exposed to internal
JS code.
Depends On D2335
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2337
This will get us both more clarity as to what types are, but also will improve switch exhaustiveness checks.
Summary: Depends On D2113
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1475409
Differential Revision: https://phabricator.services.mozilla.com/D2114
Summary:
This patch adds support for the `Sequence<T>` type. This is largely a
straightforward type propagation patch, but there are a few notable things:
1. We allow `[iid_is(x)] Sequence<nsQIResult>`, so Sequence can be Dependent.
2. `Sequence<T>` is reflected into C++ as a `nsTArray<T>`, which is different
than WebIDL's `mozilla::dom::Sequence<T>` type. This decision was made for
general ergonomics reasons, as `nsTArray<T>` is more prevailent throughout
the codebase, and lengths in this case cannot be controlled by content, as
XPConnect is only exposed to Chrome JS.
3. Owned pointers in `Sequence<T>` are not reflected as their owned
counterparts. For example, `Sequence<nsISupports>` is reflected as
`nsTArray<nsISupports*>` rather than `nsTArray<RefPtr<nsISupports>>`. This
was done to avoid depending on `RefPtr<T>` and `T*` having the same
in-memory representation, however if that is considered an acceptable
dependency, it would be nice to support that.
4. We also don't reflect singly-owned pointers as their owned counterparts. For
example, `nsTArray<nsIIDPtr>` would be reflected as `nsTArray<nsIID*>`
rather than `nsTArray<mozilla::UniquePtr<nsIID>>`. If we are willing to
depend on `mozilla::UniquePtr<T>`'s in-memory representation, we could also
do this, however.
5. There are no restrictions on what types can appear inside of a `Sequence<T>`
or what can appear inside an `[array] T`. We may want to add restrictions
either at the xpidl level or in XPConnect.
Depends On D2109
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2110
Summary:
A goal of the Sequence<T> work is to allow using more complex types within lists
in XPConnect. For example, we ideally want to support `Sequence<AString>`,
rather than requiring people to use the unergonomic 'wstring' type.
These types require initialization before they can be read into. Currently this
initialization for parameters is directly handled by XPCWrappedNative's
CallMethodHelper object.
This patch introduces a new function to the `xpc` namespace to initialize a
specific value from an uninitialized state to a safe state.
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2105
The deletions in xptcall are when we don't even have support for the CPU
in moz.configure, so I assume that people haven't been compiling on
those architectures for quite some time.
The current code is somewhat non-obvious to a first-time reader, and
OS_TEST is a bizarre thing anyway, since it's actually the name of the
CPU we're running on. We'd do well to minimize the use of OS_TEST.
Note that the complete nuking of the xptcall/md/unix/moz.build lines are
because we don't support OS X/x86 anymore.
In XPConnect, native values are passed around within nsXPTCMiniVariant objects.
an [nsXPTCMiniVariant] contains 64-bits of data in a union type.
nsXPTCMiniVariant values are created by the platform-specific glue code and
passed into XPConnect proper when calling from C++ into JS.
When calling from JS into C++, we instead create nsXPTCVariant objects and pass
them into the glue code. These objects have extra information in addition to the
nsXPTCMiniVariant: namely they also have a `type` field with the type stored in
the variant, space for flags, and a `ptr` field which is passed over IPC instead
of the inner nsXPTCMiniVariant when a flag (`PTR_IS_DATA`) is set.
The JSValue type in XPConnect is always passed as a pointer to a JSValue object,
both for in parameters and out parameters. This is handled by making the JSValue
type be unconditionally flagged as [`IsIndirect()`] This flag is also used for
all types of outparameters.
When the `IsIndirect()` flag is set, it means that the actual data is stored in
the nsXPTCVariant's val field, and it sets the flag to tell the glue code to
instead pass the `ptr` field (which is always pointing to the `val` field for
[legacy reasons]) into the C++ code.
In contrast "dipper" is a different and super weird flag. Currently only the
string class types (nsACString & nsAString) are marked as "dipper". A "dipper"
type is always passed as an "in" type (and thus always passed "directly"), even
when it's actually an out parameter.
XPConnect treats these types as though they are pointer types (nsAString*). This
means that there is no space in the nsXPTCVariant to store the actual nsAString
types when passing from JS into C++, so these values have to be allocated by a
different mechanism (in the current code, there is a size 2 buffer for each
string type in the context and once that buffer is exceeded, we heap allocate
the nsString values).
In effect, the current state looks something like this:
+------------+---------------------+---------------------+
| type | out (xpt/native) | in (xpt/native) |
+------------+---------------------+---------------------+
| TD_INT32 | indirect (int32_t*) | direct (int32_t) |
+------------+---------------------+---------------------+
| TD_JSVAL | indirect (JSValue*) | indirect (JSValue*) |
+------------+---------------------+---------------------+
| TD_ASTRING | direct (nsAString*) | direct (nsAString*) |
+------------+---------------------+---------------------+
This patch ensures there is enough space in the nsXPTCVariant to fit the
nsString value, and switches string class types to being unconditionally
indirect instead of using the dipper system. This allows us to delete a ton of
dipper-specific code, and unify the indirect and string class codepaths.
This only affects the size of nsXPTCVariant objects, and does not affect
nsXPTCMiniVariant objects. nsXPTCVariant objects are never allocated by the
platform-specific binding code, rather, they are allocated in an AutoTArray on
the stack as part of the CallMethodHelper object.
The size increase is a total of 1 word, so 4 bytes in 32-bit builds, and 8 bytes
in 64-bit builds, which is ignorable for stack allocated objects.
[nsXPTCMiniVariant]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#20-47
[`IsIndirect()`]: https://searchfox.org/mozilla-central/rev/c0d81882c7941c4ff13a50603e37095cdab0d1ea/xpcom/reflect/xptinfo/xptinfo.h#371
[legacy reasons]: https://searchfox.org/mozilla-central/rev/eb6c5214a63e20a3fff455e92c876287a8d2e188/xpcom/reflect/xptcall/xptcall.h#66-79
This type is fairly simple on the idl parsing side of things. I handle it in the
same way that special types such as ns[C]String, nsid, and jsval are handled, by
using a special native type.
The logic for converting the value between C++ and JS follows the existing logic
from the nsISupports <=> JS Promise conversions.
This patch goes through the XPConnect conversion methods, and adds cases for
T_DOMOBJECT which call the Wrap, Unwrap, and Cleanup methods from the
nsXPTDOMObjectInfo objects created in the last part.
For consistency with normal interface pointers, and because it wasn't too
complex, I also added support for including T_DOMOBJECTs in XPCOM arrays.
Due to the decision to keep the old API on nsXPTInterfaceInfo in part 4, this is
a fairly straightforward patch.
1. I had to change a couple of consumers of `IsRetval()` due to the movement of
that flag.
2. I changed all code which held a nsIInterfaceInfo to hold an `const
nsXPTInterfaceInfo*` instead.
3. I changed code which used the nsIInterfaceInfoManager to instead call the
static methods on nsXPTInterfaceInfo.
Unfortunately, I wasn't able to figure out a way to make firefox build & run in
the intermediate stages of these commits. Because of this, I am going to just
delete most of the code which I am deleting in the first patch, as I figure that
those are somewhat uninteresting changes, and then make the other changes in the
following patches.
In total, the following things are deleted:
1. All of xpcom/typelib, except for `xpt/tools` - this directory is being
subsumed entirely into xpcom/reflect/xptinfo.
2. Most of the code in xpcom/reflect/xptinfo, it is being rewritten to avoid
allocating and contain all of the necessary data structures.
3. idl-parser's typelib.py XPT generator, as it will be replaced.
4. Most includes of files which have been deleted.
NOTE: xpcom/typelib/xpt/tools/xpt.py was not removed, as it is used by bundling
code & bundling tests, which we don't want to remove yet.
nsXPTMethodInfo is a nicer structure to use, and this paves the way
for making the two types different, which will be needed if I make
XPTMethodDescriptor statically allocated.
Also, use the higher level accessor methods.
MozReview-Commit-ID: JbRdLU5Wwyt
--HG--
extra : rebase_source : 48f6c4e98e43c75006ceeb02bd727b59d3726681
Nathan Froyd
Petr Sumbera
Nika Layzell
Makoto Kato
Gijs Kruitbosch
Ehsan Akhgari
Tooru Fujisawa
Sylvestre Ledru
Adrian Wielgosik
A. Wilcox
Tom Ritter
qiaopengcheng
Cosmin Sabou
Robert Bartlensky
Bobby Holley
Jan de Mooij
Jacek Caban
David Major
Jeff Walden
Ryan VanderMeulen
Kannan Vijayan
Andrew McCreight
Chris Peterson