Oh, thanks! Did not know that pthreads already made it into incoming. Is everything always in incoming, such as also the SIMD branch? I'll try your suggestions. Thanks!
Am Donnerstag, 27. August 2015 22:45:40 UTC+2 schrieb Alon Zakai: > > 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] <javascript:>> > 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] <javascript:>. >> 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.
