lli is not reliable, I don't think the LLVM devs put much effort into it. Instead, you can use the nativizer tool to create parallel js/native builds from the same bitcode, but it is limited - will work on small source files, has not been tested on huge complete programs, tools/nativize_llvm.py.
I assume you've already taken a look at https://github.com/kripken/emscripten/wiki/Debugging , since you say you tried SAFE_HEAP etc. Have you also build with -Werror? I added that to that wiki page now. Worth verifying that SAFE_HEAP, assertions etc. were enabled (a typo in the command might lead to them not being activiated). Just for sanity's sake, seeing lots of SAFE_HEAP_LOAD commands in the output, and it running slowly, verifies it is on. It's not likely that you've hit a mistranslated instruction, because others have not hit it, and we've run fuzzers, etc. Also, if there was a compiler error of that nature, it should only show up in some compiler modes - have you tried -O0, -O1, -O2? If the problem shows up in all, it's not likely to be a codegen issue. Instead, what is more likely is you are using part of libc or GL or another API that is not tested or properly supported. You can build with LIBRARY_DEBUG=1 to emit traces on every call to JS library code, which might help. A possible but unlikely thing is a problem in your emscripten setup. You can rule that out by running the test suite, for example python tests/runner.py asm2 will run a representative part; if that passes, you should be ok there. If nothing else helps, the best route is to just find the first weird thing in the output - a misrendered image - and look at the commands that try to emit it, and debug backwards, as Jukka said. Adding printfs in the source and building natively and to the web, then comparing that, can let you focus until you find a significant difference. - Alon On Tue, May 6, 2014 at 4:55 AM, Christoph Husse <[email protected] > wrote: > >> >> It may well be that lli doesn't work with emscripten's bitcode any longer >> after the change to the current target triple. >> >> >> > Well that would be really bad. How else would I be able to find the > offending machine instruction that might be translated the wrong way by > Emscripten in millions of statements? > > Also I think its a C++ issue. I have now started to replace things like > std::vector<> & stuff with my own ultra slim & simple implementations which > basically all come down to a single "realloc". So far I have been able to > successfully compile & run my above sample program without modification > (except that I am no longer using libcxx, but my own C++ headers). > > I think for now I may go down the route of just replacing all C++ > specifics with my own super-simple implementation so that LLI doesn't choke > itself. But I fear that as soon as I start incorporating the huge game > library, there will be stuff that breaks even with all my own headers. > > -- > 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.
