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] <javascript:>> > 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] <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.
