Closed Bug 505907 Opened 15 years ago Closed 13 years ago

Support C++ calling from JSctypes

Categories

(Core :: js-ctypes, defect)

Product:
Core
Component:
js-ctypes
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: taras.mozilla, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(Whiteboard: [snappy][ts]) 

Andreas mentioned that this wouldn't be hard. I think we need that as a first step away from xpconnect. Would be nice if someone could figure out how to make it work for calling C++.
Whiteboard: [ts][tsnap]
Blocks: 412531
(In reply to comment #1)
> You want jsctypes: https://wiki.mozilla.org/JSctypes .

yes, but I want to call C++.
PInvoke of course doesn't really do C++, for the same reasons that it's hard for us.  But you could file a bug on the JSctypes project to get whatever subset-of-C++ calling you specifically want (see the bottom of that page for the Bugzilla component info).  Tempted to close this bug in favour of one focused on C++ in the jsctypes component.

Do we have reason to believe that PInvoke would be faster than XPConnect in a useful way?  Just wondering a the [Ts] and [Tsnap] annotations here.
I haven't benchmarked, but I was hoping that it would be cheaper than 0.2ms per xpconnect call on n810. You can close it as a dup if we plan on getting jsctypes C++ subset stuff into the tree.
What specific C++ types do you need to manipulate?
i think i'd be ok with basic c types for now, but I want to be able to call virtual methods on a pointer.
I think libffi can do that, no?
(In reply to comment #7)
> I think libffi can do that, no?

Dude! I somehow missed that libffi feature. I'll have to test it out.
 I'd close this bug, but not sure which jsctype bug to use instead of this one.
Assignee: general → nobody
Component: JavaScript Engine → js-ctypes
Product: Core → Other Applications
QA Contact: general → js-ctypes
Summary: add a pinvoke-like method to js → Support C++ calling from JSctypes
We just need somebody to shepherd it to testing and completion ;-)
Product: Other Applications → Core
Version: Trunk → unspecified
For some stuff I'm working on, the ability to use thiscall convention for a call would be wonderful. I don't think libffi supports thiscall conventions, but I should note that xpcom/reflect/xptcall has a large amount of thiscall code ;-).
This wouldn't be hard to add - for gcc you basically get it for free; for msvc, we already have a libffi_msvc fork, which you could add it to. (Tweaking the existing assembly to pass a pointer in ecx would probably be quite easy.)

The vtable bit would be a bit stickier. To get at the function pointer for an arbitrary virtual method you need two-and-a-half things:

0) The thunk, if any, to get to the derived class. Let's ignore this and assume we have a pointer to the correct instance.

1) The offset of the vtable pointer within the class instance. (Let's assume this is zero for all useful compilers for now, as it is with gcc, but this may not be true.)

2) The offset of the virtual method in question within the vtable. Let's say you know this.

In that case, the minimal ctypes API is something that says "call this function pointer", and you can do the vtable arithmetic yourself. Something more usable might say "call the 5th virtual method on this class", and the endgame would be "here's my class heirarchy and layout; parse it, figure out the arch-dependent offsets, and fetch the function pointer at call time".
(In reply to comment #12)
> The vtable bit would be a bit stickier. To get at the function pointer for an
> arbitrary virtual method you need two-and-a-half things:

With suitable hackery, I believe NS_InvokeByIndex can handle arbitrary vtable calls. In any case, the particular use case I'm more concerned about doesn't involve vtable arithmetic.

> In that case, the minimal ctypes API is something that says "call this function
> pointer", and you can do the vtable arithmetic yourself. Something more usable
> might say "call the 5th virtual method on this class", and the endgame would be
> "here's my class heirarchy and layout; parse it, figure out the arch-dependent
> offsets, and fetch the function pointer at call time".

In the true endgame, this could replace start replacing xpconnect in simple cases :-).
No longer blocks: 412531
Blocks: 447581
Depends on: 552533
If we're going to scope this, at least initially, to "parity with xpconnect", then we want to go the compiler-generated-metadata route. So at build time, we'd have xpidl call up a new parser -- let's call it ctypesidl -- which takes the class specification and generates JSON for all the class info.

We'd then have a ctypes JS API, intended for internal use and thus subject to evolve, which takes this JSON and creates, say, a ClassType object that has all the virtual methods on it. In the script, you'd include the generated JSON, which would set up the appropriate ClassType objects.

No name mangling, no pretty API for JS consumers, just something minimal. This wouldn't be hard, just a bunch of code to write.
(In reply to comment #14)
> If we're going to scope this, at least initially, to "parity with xpconnect",

I should clarify, lest anyone explode -- I meant "the ability to call virtual functions as declared in an idl".

Also, if we implement this, we're going from ctypes and xpconnect being mutually exclusive in functionality to having overlap. Therefore we want to make sure there's an upside to doing so. Performance results here would help.
Note that we've already got xpidl.py:
http://mxr.mozilla.org/mozilla-central/source/xpcom/idl-parser/

which is being used for quickstubs.
Whiteboard: [ts][tsnap] → [snappy]
Whiteboard: [snappy] → [snappy][ts]
No immediate need for this
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX
(In reply to Taras Glek (:taras) from comment #17)
> No immediate need for this

So just because you don't need it right now, you decide that it will never be fixed?
I thought that would be a reason for setting it to low priority but keep it open as something to be done at some date. If we are serious on replacing XPCOM completely in the long term, we need this or an equivalent, I don't see how we can say it's not in our plans to be done at some point, which is what I though that WONTFIX meant.
I don't think there is value in keeping this bug open: we don't want this to be implemented without a specific understanding of how somebody (internal or external) would actually use it, and deciding what we do and don't want to support. This bug doesn't provide any of that and so I'd like it to stay closed. If anyone wants to think about this in the future, please email mozilla.dev.platform and we can discuss the specifics and get a spec written.
it would be super cool if someone wrote some examples using XPCOM and other firefox internals via vtable's from js-ctypes. i dont know how ff internals work so i dont know if this is possible. just would be nice :P like to use HashString: https://dxr.mozilla.org/mozilla-central/source/mfbt/HashFunctions.h#294
http://mxr.mozilla.org/mozilla-release/source/widget/windows/WinTaskbar.cpp#254
I started some documenation on using c++ from js-ctypes i did it for winapi com if anyone can add to it or make a seperate page for C++ that would be awesome:

https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes/Examples/Using_COM_from_js-ctypes#Converted_js-ctypes_code
Hi, just a msg here, because I wanted to call DLL/c++, and I've got a lot of trouble ...
But finaly, it works like a charm, with the help of https://github.com/ochameau/jscpptypes
If I had found this pointer before, It could save me 5days at least ;-)
Hope It can help someone in the future !
You need to log in before you can comment on or make changes to this bug.