pthreads has already been merged to incoming, so you can use that. (Unless there is another pthreads branch I'm not aware of?)
I believe dlsym should work on the same process, on a main module. Not sure, if not, please file an issue. On Thu, Aug 27, 2015 at 12:30 PM, <[email protected]> wrote: > I am basing my work on juj's pthreads branch, since I need threading more > than I need dynamic linking. And I think, juj's pthreads branch does not > contain support for dl functions? > Also, can I use dlsym to lookup symbols in "this" process, instead of in a > shared library? > > Thanks! > > Am Donnerstag, 27. August 2015 02:22:26 UTC+2 schrieb Alon Zakai: >> >> Why not use dlsym? An emscripten shared module (SIDE_MODULE=1) has the >> semantic information to map function names to function pointers. You can >> also use it directly without dlsym if you prefer, the module basically >> returns a object that maps symbol names to values (and for a function, the >> value is a function pointer). >> >> Once you have the function pointer, you can then call it. Use >> Module.dynCall_* where * is the type. Again, looking at the output of a >> shared module might be the easiest way to see how this can work. >> >> On Wed, Aug 26, 2015 at 12:05 PM, <[email protected]> wrote: >> >>> Hi Alon, >>> >>> thanks for answering. Sorry, it has been a while since I attacked this >>> problem. >>> Now, I give it another try. >>> >>> So, please let me explain my concrete problem: >>> >>> My concrete problem is that a language unlike C/C++ or any other >>> language that can be compiled via Emscripten, in particular that language >>> is Java, uses a mechanism called "Java Native Interface" to declare and >>> link to native functions at runtime. >>> Concretely those native functions are themselves implemented in C in the >>> gnu classpath library and are compiled and archived via Emscripten into .a >>> files. >>> This process works perfectly with Emscripten! >>> But, the process of invoking that function is not from C and does not >>> have function prototypes/signatures to compile against. >>> The Java Virtual Machine, while interpreting the Java bytecode files, >>> sees that a "native" method is about to be invoked. >>> Then, it looks up the pointer to the corresponding native function >>> (question: "how do I lookup a native function dynamically with Emscripten >>> at runtime without using dlsym and all the dynamic library features?"). >>> After the native function was found, the arguments are being put on the >>> C stack via some mechanism (in a desktop JRE this is done via x86 assembly >>> code or the libffi), and then the function is called through the function >>> pointer. >>> Now, my question is concretely: How would I achieve this? I know how to >>> link everything in a static library, as one should do that with Emscripten. >>> But now I do not know how to lookup the pointer to a function in the >>> process and how to pass arguments from C to its JavaScript "native" >>> function. >>> >>> Thanks! >>> Kai >>> >>> Am Montag, 4. Mai 2015 21:45:31 UTC+2 schrieb Alon Zakai: >>>> >>>> Maybe I wasn't understanding you before. A concrete code sample might >>>> help. >>>> >>>> - Alon >>>> >>>> >>>> On Thu, Apr 30, 2015 at 2:13 PM, <[email protected]> wrote: >>>> >>>>> Thank you for your answer! >>>>> >>>>> Although I am totally not getting anything from that 19 lines of test >>>>> case and how anything is supposed to work with that, let alone what that >>>>> test case is actually doing. Looks very cryptic to me. :) >>>>> But if you say it's gonna work this way, then I will try further. >>>>> >>>>> I just don't know how it can be possible to invoke a function whose >>>>> signature I cannot express in C code at compile time with a prototype, >>>>> since the actual signature is encoded via some other mechanism as a string >>>>> that I can query at runtime, such as "(II)V", meaning "take two integers >>>>> and return void". >>>>> >>>>> And I don't know how to put arguments from the emscripten HEAP on the >>>>> C stack and call that function then. >>>>> >>>>> dlfnc symbols seem to be needing a compile-time function prototype to >>>>> cast against before invoking the function. >>>>> But I don't have that. And I think that's also the problem that libffi >>>>> is solving with all that assembler magic, because one has no function >>>>> prototype/signature at compile time. >>>>> >>>>> So the original question was whether it would then make more sense to >>>>> generate asm.js code during runtime which is able to decode the signature >>>>> string (i.e. the "(II)V") of the function into a real JavaScript function >>>>> invocation. >>>>> >>>>> Thanks again! >>>>> >>>>> Am Samstag, 25. April 2015 10:26:53 UTC+2 schrieb >>>>> [email protected]: >>>>>> >>>>>> Hi there, >>>>>> >>>>>> I was wondering what would be a possible solution to dynamically call >>>>>> an Emscripten-compiled function within the same application (no dynamic >>>>>> library). >>>>>> The issue is that during compile-time I do not know the target >>>>>> function's signature and therefore do not have static C caller code that >>>>>> could invoke the required function, but must instead build such code >>>>>> during >>>>>> runtime. >>>>>> >>>>>> For native languages there exists libffi for exactly this purpose and >>>>>> it is using assembler code to put function arguments on the stack. >>>>>> I was wondering what the best approach with emscripten is to link a >>>>>> dynamic function call to its target function. >>>>>> The information I have at a possible caller-site is: (function name, >>>>>> function signature, base stack pointer on the heap of the first >>>>>> argument). >>>>>> I was thinking about dynamically building a small asm.js module which >>>>>> reads the arguments from the heap starting at the base pointer and which >>>>>> then builds an appropriate function call. >>>>>> This script I would then eval() in order to get an asm.js-compiled >>>>>> libffi-like interface. >>>>>> >>>>>> Would this be a viable approach? >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Kind regards, >>>>>> Kai >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "emscripten-discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "emscripten-discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
