{"action":"created","issue":{"url":"https://api.github.com/repos/WebAssembly/binaryen/issues/370","repository_url":"https://api.github.com/repos/WebAssembly/binaryen","labels_url":"https://api.github.com/repos/WebAssembly/binaryen/issues/370/labels{/name}","comments_url":"https://api.github.com/repos/WebAssembly/binaryen/issues/370/comments","events_url":"https://api.github.com/repos/WebAssembly/binaryen/issues/370/events","html_url":"https://github.com/WebAssembly/binaryen/issues/370","id":149849560,"number":370,"title":"The compiler-rt problem","user":{"login":"dschuff","id":1122856,"avatar_url":"https://avatars.githubusercontent.com/u/1122856?v=3","gravatar_id":"","url":"https://api.github.com/users/dschuff","html_url":"https://github.com/dschuff","followers_url":"https://api.github.com/users/dschuff/followers","following_url":"https://api.github.com/users/dschuff/following{/other_user}","gists_url":"https://api.github.com/users/dschuff/gists{/gist_id}","starred_url":"https://api.github.com/users/dschuff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dschuff/subscriptions","organizations_url":"https://api.github.com/users/dschuff/orgs","repos_url":"https://api.github.com/users/dschuff/repos","events_url":"https://api.github.com/users/dschuff/events{/privacy}","received_events_url":"https://api.github.com/users/dschuff/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2016-04-20T18:32:22Z","updated_at":"2016-05-11T18:37:05Z","closed_at":"2016-05-11T18:37:05Z","body":"Compiler-rt is a library containing functions, to which the compiler may emit calls during code generation. It includes a variety of functionality, but most notably functions for operations on types which the compiler can't generate directly (for example long doubles on wasm or 64-bit integers on asm.js). `memcpy` and friends are also in this category (calls to them can be emitted during codegen) but they are not actually in the compiler-rt library. Unlike an ordinary library (where dependencies on that library can be seen at bitcode link time), dependencies on compiler-rt functions do not appear until after final code generation.\r\n\r\nIn a traditional system, linking happens after all code generation is done, so compiler-rt can just be an ordinary native library included at the end of the link. Even when using LTO (in which case the user code is linked as bitcode) there is a native link step, which includes the native user code, native system libraries, and compiler-rt.\r\n\r\nAll of asm.js, PNaCl, and (currently) WebAssembly all use bitcode linking and so have the problem that the dependencies on compiler-rt are not visible at bitcode link time. PNaCl has a second (native) link step that happens on the client and includes some libraries provided by the browser as well as compiler-rt. \r\nThat works well but it's not an option for asm.js or wasm, where we consider the \"final\" format to be JS or wasm, and need to ship everything to the client. For asm.js, emscripten effectively has a second native (i.e. JS) \"link\" step where it copies asm.js implementations of `__muldi3` and other int64 functions into the asm module when needed.\r\n\r\nFor WebAssembly in the long term, we want to have a model that looks more like the traditional one, in which linking can happen over the \"native\" (i.e. binary wasm) code after codegen. In that case compiler-rt can look just as it does for native platforms today. (We also do want to support LTO but there can still be a native link step as there is for LTO on native platforms). In the near term however, we are still using bitcode linking as implemented by emscripten. So we need to solve this problem. I see a couple of possibilities.\r\n\r\n* The simplest thing would be to always link everything (where \"everything\" basically means the long double functions today) in. That's a bad idea because it would cause bloat (although it's not quite as bad an idea as it should be, because any use of `printf` today would cause them to be included anyway). But in any case it doesn't scale past just the long double functions.\r\n* Do something like what emscripten does for asm.js and implement some kind of special custom second-stage link (which would be on the generated .s or .wast code). This would make emscripten's linking even more complex than it already is, and not fit with the goal of making wasm easy (or even possible) to use independently of emscripten and the web.\r\n* Do a native link-like step in a binaryen tool such as s2wasm. s2wasm really has 2 jobs; parsing LLVM's .s format into wasm AST, and doing the relocation/layout portion of the linker's job. As part of the latter job it also can allocate the user stack (and the stack pointer) and `__dso_handle` (which is usually part of a toolchain runtime file such as `crtbeginT.o`). It would probably be straightforward to implement a (very!) simple \"linking\"-like step to pull already-generated implementations of compiler-rt functions (either in .s or .wast format) into the module.\r\n\r\nI propose we do the latter. In fact I'm thinking of splitting the existing linking functionality (e.g. `fix()`) out of `S2wasmBuilder` and into its own class anyway. This would solve the problem, re-use code that we already have that is related, and do so in a way that is most like the solution we want in the long term, \r\n"},"comment":{"url":"https://api.github.com/repos/WebAssembly/binaryen/issues/comments/218550182","html_url":"https://github.com/WebAssembly/binaryen/issues/370#issuecomment-218550182","issue_url":"https://api.github.com/repos/WebAssembly/binaryen/issues/370","id":218550182,"user":{"login":"dschuff","id":1122856,"avatar_url":"https://avatars.githubusercontent.com/u/1122856?v=3","gravatar_id":"","url":"https://api.github.com/users/dschuff","html_url":"https://github.com/dschuff","followers_url":"https://api.github.com/users/dschuff/followers","following_url":"https://api.github.com/users/dschuff/following{/other_user}","gists_url":"https://api.github.com/users/dschuff/gists{/gist_id}","starred_url":"https://api.github.com/users/dschuff/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dschuff/subscriptions","organizations_url":"https://api.github.com/users/dschuff/orgs","repos_url":"https://api.github.com/users/dschuff/repos","events_url":"https://api.github.com/users/dschuff/events{/privacy}","received_events_url":"https://api.github.com/users/dschuff/received_events","type":"User","site_admin":false},"created_at":"2016-05-11T18:37:05Z","updated_at":"2016-05-11T18:37:05Z","body":"With https://github.com/kripken/emscripten/pull/4294 landed I'm going to go ahead and close this. There will be more changes to the linking functionality but the blocking problem and proposal is done."}}