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.
