I'm just starting to play around with Emscripten, but I've run into something odd, when trying to export functions, for use in JavaScript. The test project has to do with libsquish, but it's not really relevant for the question, other than the header/code filenames.
So - anyway, simple test.
c/c++
//squish.h
extern "C" int main();
int main();
extern "C" int gsr();
int gsr();
//squish.cpp
int main()
{
return 99;
}
int gsr()
{
//return squish::GetStorageRequirements(width,height,flags);
return 8675309;
}
Additional Options/Command Line
-s EXPORTED_FUNCTIONS="['_gsr','_main']"
Javascript
main=Module.cwrap('main','number',null);
console.log(main());
GetStorageRequirements = Module.cwrap('gsr', 'number',null);
console.log(GetStorageRequirements());
Javascript Console (Chrome)
99
Assertion failed: Cannot call unknown function gsr (perhaps LLVM optimizations or closure removed it?)
Assertion failed: Cannot call unknown function gsr (perhaps LLVM optimizations or closure removed it?)
And on top of everything else, optimization is disabled (O0).
So, what's the deal here? Same return types, same number of parameters, defined in exactly the same way, with the only difference being the name of the function. Yet one works, and the other is "unknown".
The only possible, logical cause is that it's automatically exporting main, and ignoring the EXPORTED_FUNCTIONS all together. But if that's the case, I have no idea why.
Thanks to Charles Ofria's work in narrowing down the issue, the only real oddity ended up being with the Emscripten Visual Studio plugin. I was on the right track, when I thought that it might just be automatically exporting main - which was correct. The reason it wasn't exporting the other function, was because I put it in the Additional Options, for the Clang/C++ section, instead of the Emcc Linker.
The trouble was, and this is where the "oddity" comes in, the Emcc Linker section doesn't appear when you choose Console Application (.js) as the Configuration Type. So, after changing the Target Extension to .html and the Configuration Type to Browser Application (.html) - the Linker section re-appeared, and I was able to put the EXPORTED_FUNCTIONS option, in the correct location.
After building, and copying the output over, both functions were defined, and returned the proper values in the Javascript console.
Probably the issue here is C++ name mangling. That's a C++ filename, so "gsr" turns into something like "_Z3gsr". You can avoid that by making it a C file, or using extern "C" around that method.
For more see http://kripken.github.io/emscripten-site/docs/getting_started/FAQ.html#why-do-functions-in-my-c-c-source-code-vanish-when-i-compile-to-javascript-and-or-i-get-no-functions-to-process
Related
Sorry if this is a trivial question, so if this has already been asked, please direct me to the question.
I know that the tostring method in javascript, if called on a function will print the source code (more about it: link). Is it possible to do the same thing in Java?
So if I have the following identity function definition:
public class class1 {
int f1(int x){
return x;
}
}
And the following main function:
class Main {
public static void main(String args[]) {
class1 c1 = new class1();
????
}
}
Is there anything I can put in place of '????' that would print something like
int f1(int x){
return x;
}
Disclaimer: I'm not an expert at Java, or any programming language for that matter. However, I do know how to find information online.
This concept does not seem very doable within Java. To start:
JavaScript is an interpreted language, not a compiled language. A program such as C++ or Java needs to be compiled before it is run. The source code is passed through a program called a compiler, which translates it into bytecode that the machine understands and can execute. In contrast, JavaScript has no compilation step. Instead, an interpreter in the browser reads over the JavaScript code, interprets each line, and runs it. More modern browsers use a technology known as Just-In-Time (JIT) compilation, which compiles JavaScript to executable bytecode just as it is about to run.
Basically, JavaScript has the advantage of reading directly from the file with the source code, and executing it on the fly. Compiled languages such as Java won't have that sort of functionality built in by default for many reasons, including security. An application should be able to run without allowing hackers access to its source code as much as possible.
There have been attempts at doing various forms of what you're interested in, but the two easiest methods seem to be
Printing the original .java file line by line
Storing a string reference to the entire code or the method(s) required.
It also seems possible to print the method name, but not the body.
Aside from that, the only thing you might be able to get from a compiled, running java program, is bytecode, which would require a decompiler to have any hope of understanding the source behind it.
You can continue reading up on it through a few of the links here:
How do I print the method body reflectively?
Save a method into a variable, java 8
View a method's implementation (method body) using Java Reflection
Probably yes, but not a trivial one with a ready command. JavaScript is an interpreted language where the executing environment has access to the source code in its original form. That is how you can inspect it in a browser console and see the same variable names as are in the source code.
While the compiled/interpreted distinction is fuzzy for Java, it is definitely modified before execution. The bytecode used by Java's Just-in-Time compilation may be more readable than a fully compiled binary file, it is not the source. If the running program does not have access to the source code, it is less able to output it. A debugger running in an IDE can reference problems in the source; otherwise, you are limited to debugging the bytecodes.
This is why Keno Clayton suggested the question on Quine programs, which are meant to reproduce themselves. This answer outputs the source code by hard-coding it as a class attribute. You could take a similar approach with a pre-compilation script that went through all the methods and made strings out of their sources, but the result would be bulky and potentially sensitive.
I'm learning v8 now, but I have encountered some problems.
How to set a breakpoint a method's start address in memory if I want to debug a method's C++ implementation.
e.g. var a= new Array(0,1); a.indexOf(1) ; I want to set a breakpoint at slice's beginning, or are there other ways to track the assembler code ?
There are a lot of functions will be complied and writed into a file named snapshot.bin. so I can't set a breakpoint at the beginning of these functions.
You need to check the source code and find the implementation of slice. Then set a gdb/lldb break point in that .cc file: byiltins-typedarray.cc
A lot of functions are defined as builtin or runtime functions.
It depends on the kind of function you want to inspect.
You can compile without snapshot to get around snapshot-related debugging difficulties (at the cost of making startup quite a bit slower: several seconds in Debug mode).
You can modify the respective code generator to emit a break instruction at the beginning of the function. For the example of Array.indexOf, that's probably the easiest solution; the CodeStubAssembler instruction is called DebugBreak().
You can break somewhere else using GDB, find your way to the function in question (e.g. via isolate->builtins), and set a breakpoint on the address of its entry. (This requires a bit of V8 knowledge and/or code reading skills, but it's not difficult.)
You can use various --print-*-code flags to print code to stdout (without breaking on it).
I have a C++ project that I compile to Javascript using emscripten. This works, however, for resource limits and interactivity reasons I would like to run this inside a webworker.
However, my project uses the stdin. I found a way to provide my own implementation of stdin by overwriting Module['stdin'] with a function that returns a single character at a time of the total stdin, and closes with 0 as EOF.
This works when the script runs inside the page, as the Module object present in the html file is shared with the script.
When you run as a webworker though, this module object is not shared. Instead, message passing makes sure the regular functionality of Module still works. This does not include 'stdin'.
I worked around this by modifying the output javascript:
A: Adding an implementation of a Module object that includes this stdin specification. This function is modified to read a variable of the webworker as if it were the stdin and feed this on a per-character basis.
B: Changing the onmessage of the webworker to call an additional function handling my own events.
C: This additional function listens to the events and reacts when the event is the content of stdin, by setting the variable that the stdin function I specified reads.
D: adding and removing run dependencies on this additional event to prevent the c++ code running without the stdin specified.
In code:
Module['stdin_pointer'] = 0;
Module['stdin_content'] = "";
Module['stdin']=(function () {
if (Module['stdin_pointer'] < Module['stdin_content'].length) {
code = Module['stdin_content'].charCodeAt(Module['stdin_pointer']);
Module['stdin_pointer']=Module['stdin_pointer']+1;
return code;
} else {
return null;
}
});
external = function(message){
switch(message.data.target){
case 'stdin' : {
Module['idpCode'] = message.data.content;
removeRunDependency('stdin');
break;
}
default: throw 'wha? ' + message.data.target;
}
};
[...]
addRunDependency("stdin");
[...]
//Change this in the original onmessage function:
// default: throw 'wha? ' + message.data.target;
//to
default: {external(message);}
Clearly, this a & c part is quite easy because it can be added at the start (or near the start) of the js file, but b & d (adding your own dependencies and getting your own messagehandler in the loop) requires you to edit the code inline.
As my project is very large, finding the necessary lines to edit can be very cumbersome, only more so in optimized and mimified emscripten code.
Automatic scripts to do this, as well as the workaround itself, are likely to break on new emscripten releases.
Is there a nicer, more proper way to reach the same behavior?
Thank you!
//EDIT:
The --separate-asm flag is quite helpful, in the respect that the file that I must edit is now only a few lines long (in mimified form). It greatly reduces the burden, but it is still not a proper way, so I'm reluctant to mark this as resolved.
The only way I know of achieving what you want is to not use the Emscripten-supplied worker API, and roll your own. All the details are probably beyond the scope of a single question, but at a high level you'll need to...
Compile the worker module with your processing code, but not using the BUILD_AS_WORKER flag
At both the UI and worker ends, you'll need to write some JavaScript code to communicate in/out of the C++ worlds, using one of the techniques at http://kripken.github.io/emscripten-site/docs/porting/connecting_cpp_and_javascript/Interacting-with-code.html, that then directly calls the JavaScript worker API https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers
At the Worker side of this, you will be able to control the Module object, setting stdin as you see fit
As a side-note, I have found that the Emscripten-supplied C++ wrappers for JavaScript functionality, such as workers, graphics, audio, http requests etc, are good to get going at first, but have limitations and don't expose everything that is technically possible. I have often had to roll my own to get the functionally needed. Although not for the same reasons, I have also had to write my own API for workers.
I have a simple function written in python which I want to port to javascript.
I have compiled python 2.7 into a .so library, so thats not the issue.
The problem I'm having is that after I compile my program with cython, the function names get all scrambled up, which means I don't know how to preserve the functions when i run emcc.
Does anybody have any experience compiling python programs to js with emscripten?
Any information would be appreciated.
Note: I want to preserve the exact functionality to that of python, I don't want something that translates a python program into javascript.
This other question, with an accepted answer, complains about the same issue: Cython mangling function names and making it difficult to access from C++: Embed python function in C++
The accepted answer states that Cython isn't meant for this sort of thing at all, suggesting you can't do what you want in this fashion:
You're not going to be able to get the interoperation you want that way. If you open and inspect hello.c you won't find "static int say_hello" anywhere in there. Cython is designed for letting Python use C libraries, not letting C libraries use python.
The not-accepted next answer suggest that specifying public will not mangle the function name, although he also mentions linking problems.
# (in the generated C file hello.c)
__PYX_EXTERN_C DL_IMPORT(...) say_hello(...);
Worth a shot, but please consider the other options in the comments if it fails.
I am in the process of ironing out my codebase so it can compile with ADVANCED_OPTIMIZATIONS on google's closure compiler.
After properly setting up the debugging environment required for this task (source map file, chrome, wrapping the compiled js file) i stumbled upon try catch issues. It appears that extensive use of try/catch statements in my codebase has backfired on me.
On almost all methods and functions i use a typical try { } catch(e) {ss.error(e);} statement, where ss.error() is a generic error handler that depending on environment either prints out debug stuff or reports back the exceptions...
In the process of ironing my codebase, when i get an error that i need to fix, what happens is that instead of having Chrome report the offending file and line, it points to the error handler ss.error(). Thus leaving me with no way of backtracing the problem. The ss.error() func however, does print where the problem originated from:
Error! type:TypeError at Db (/jsc/compiled.js:547:246) msg:Cannot call
method 'ka' of undefined source:
After i get these type of errors i have to do two steps:
1. Fiddle with the compiled code at line 547 char 246 and try to figure out which part in my uncompiled code this refers to...
2. After i locate it, remove the try/catch blocks so i can directly and more clearly see what caused the error...
I must say i am not happy with this workflow and need to find an alternative that will both allow me to properly catch exceptions and debug my compiled and uncompiled code while retaining mind sanity =)
I was thinking of somehow using the Line:CharPosition info to query the source map and have the ss.error() function do the mapping to my uncompiled source code...
ideas?
There is a java interface to the SourceMaps as part of the closure compiler. There are also JS implementations in various states of repair. I try to keep links to them up to date here:
http://code.google.com/p/closure-compiler/wiki/SourceMaps
For the Java implementation you simply load the source map using the SourceMapConsumerFactory, the interface is pretty simple.