On Sat, Jun 29, 2019 at 8:31 AM Tapan Anand <[email protected]> wrote: > > Hi Sam, > I see that error during runtime, when that branch of code is hit. Is there > a way for them to atleast show up at load time so I can be sure that user > wouldn't encounter any new errors in production? >
There is no way currently but it could be added. Do you want to open an issue requesting this feature? > On Saturday, 29 June 2019 01:17:22 UTC+5:30, Sam Clegg wrote: >> >> On Fri, May 31, 2019 at 1:25 AM Tapan Anand <[email protected]> wrote: >> > >> > So does that mean its possible to miss some missing symbols as well since >> > runtime errors seems to be the only way to determine them? >> >> Yes, they are currently runtime errors, because dynamic linking >> happens at runtime. Are you seeing them show at at startup or after >> main runs? We should at least be able to ensure these are load time >> errors. >> >> Ideally we would build a system where the MAIN_MODULE and the >> SIDE_MODULE can be built in such a way that can know that list of >> symbols needed by the other modules. However because we have a lot of >> circular dependencies this could prove a little tricky. >> >> > >> > On Friday, 31 May 2019 03:49:27 UTC+5:30, Alon Zakai wrote: >> >> >> >> Yes, in general the optimizer may remove anything it does not see is >> >> used, in normal compilation, and in main module/side module mode 2. It's >> >> possible some things stay alive anyhow since they are used by other >> >> things. But if nothing else uses it, you must add it to the exports >> >> yourself, or the optimizer may remove it. >> >> >> >> On Wed, May 29, 2019 at 1:10 PM Tapan Anand <[email protected]> wrote: >> >>> >> >>> Thanks for the quick reply Alon! >> >>> The C library functions puts and printf work with MAIN_MODULE=1 but the >> >>> new and delete operator errors still persist if I don't manually export >> >>> them. >> >>> Regarding - "which means you need to carefully pick what is kept alive >> >>> for the other modules", so you mean we have to add these mangled names >> >>> in the export list if we use MAIN_MODULE=2 and there is no other way to >> >>> avoid this? MAIN_MODULE=1 creates a huge .js and .wasm file and hence >> >>> ends up increasing the MAIN_MODULE size while the purpose of dynamic >> >>> linking for me is to reduce its size. >> >>> Also, I got to know about new and delete via runtime errors, but what if >> >>> I some part of code is not encountered while testing (and hence no >> >>> runtime error occurs)? That may cause unknown crashes when the user uses >> >>> the app for example, is that expected? Or there is a way to know >> >>> unresolved symbols in advance using some technique? >> >>> >> >>> On Thursday, 30 May 2019 00:00:45 UTC+5:30, Alon Zakai wrote: >> >>>> >> >>>> This is probably because of MAIN_MODULE=2, which means you need to >> >>>> carefully pick what is kept alive for the other modules. Does this work >> >>>> with =1? If so then that's the issue. The test suite has a bunch of >> >>>> examples for mode 2, that might help. >> >>>> >> >>>> On Wed, May 29, 2019 at 3:40 AM Tapan Anand <[email protected]> >> >>>> wrote: >> >>>>> >> >>>>> Hi, >> >>>>> >> >>>>> I was trying to use dynamic linking using dlopen with emscripten >> >>>>> compiler version 1.38.28 and encountered the following problem: >> >>>>> >> >>>>> 1. When I try to use vector in the SIDE_MODULE, it can't seem to find >> >>>>> the new and delete operators in the Module variable. >> >>>>> >> >>>>> 2. The command I use to build main and side module are: >> >>>>> >> >>>>> >> >>>>> em++ doubler.cpp -o doubler.wasm -s SIDE_MODULE=1 -O3 -s >> >>>>> "EXPORTED_FUNCTIONS=['_doubler']" >> >>>>> EMCC_FORCE_STDLIBS=1 em++ main.cpp -O3 -s WASM=1 -s MAIN_MODULE=2 -o >> >>>>> dynlink.js -s "EXPORTED_FUNCTIONS=['_main', '_clock', '_tripler', >> >>>>> '_printf', '_puts']" -s "DEFAULT_LIBRARY_FUNCS_TO_INCLUDE=['clock']" >> >>>>> -s FORCE_FILESYSTEM=1 --pre-js prejs.js >> >>>>> >> >>>>> >> >>>>> The prejs file here is there to use FS.createLazyFile to cause lazy >> >>>>> loading of the side module. >> >>>>> >> >>>>> If I change the exported function list in main_module to `['_main', >> >>>>> '_clock', '_tripler', '__Znwm', '__ZdlPv', '_printf', '_puts']` It >> >>>>> starts to work. Notice that I had to add the mangled symbols of new >> >>>>> and delete operator to export list. >> >>>>> Also, once I did this, I didn't get any missing symbols related to the >> >>>>> vector class itself. >> >>>>> >> >>>>> So, I have two questions: >> >>>>> 1. Do we have to export C++ runtime functions like new, delete, or >> >>>>> even c runtime methods like printf, puts for code to work? Is that >> >>>>> expected? >> >>>>> 2. Since there were no errors for vector related symbols, does that >> >>>>> mean that vector is linked with the side_module? If I also use vector >> >>>>> in main module, will there be effectively two copies of vector? In >> >>>>> both side and main module? >> >>>>> >> >>>>> Thanks in advance! >> >>>>> >> >>>>> -- >> >>>>> 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]. >> >>>>> To view this discussion on the web visit >> >>>>> https://groups.google.com/d/msgid/emscripten-discuss/5f2ad4c5-fc8e-45a3-afab-e340f91f09f5%40googlegroups.com. >> >>>>> 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]. >> >>> To view this discussion on the web visit >> >>> https://groups.google.com/d/msgid/emscripten-discuss/058436c9-50d5-4a13-a499-cbca19214066%40googlegroups.com. >> >>> 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]. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/emscripten-discuss/f5c8beed-0aee-4a0f-8748-17321afb48dd%40googlegroups.com. >> > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/e30016f3-0de3-4d3f-9c35-538b4f58e6db%40googlegroups.com. > 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-Y47MnLBa9MeiB_rcRYXiP244ky3-TSc8vMUKfXXjpQA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
