-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support DWP files #13251
Comments
I submitted https://reviews.llvm.org/D93749 to make llvm-dwp also generate wasm files. |
Oh, great! You don't need me to land that for you, correct? |
Landed! |
Are there more known issues with DWP generation for wasm? |
Not that I know of. What's still missing is making llvm-dwp available through emscripten. |
There is still the open issue of WebAssembly/binaryen#3506. Split-dwarf and binaryen can't work together. |
Thanks, I think we just need to adjust the waterfall script to include llvm-dwp. I'll keep this open until we do that. I also filed WebAssembly/binaryen#3518 |
Sounds reasonable, and thanks for filing the binaryen bug! We might also consider additionally supporting emcc as a driver for llvm-dwp, so that build systems don't need to figure out where the right llvm-dwp binary lives. Bundling llvm-dwp is the right first step though! |
Yeah, that's an interesting question. At minimum it probably makes sense to package any tool that's invoked directly by build systems alongside emcc (e.g. we already have emar and emranlib). Ideally build systems like CMake would be able to model dwo/dwp files (and the relevant tools) natively for platforms that use them; in that case we'd just want to model those systems as closely as possible. But it doesn't look like native support (at least for CMake) is there yet. So then it's a question of, do we try really hard in the driver to paper over this, and either have a flag that invokes dwp, just always default to using dwp files, or something like that? Or do we try to make it easier to use without doing that (perhaps e.g. with some support in our CMake toolchain file, docs, etc). I wonder why gcc/clang's native dwp support isn't driven by the compiler driver? Maybe it's got something to do with the traditional unix build-system model where only one file comes out of each tool invocation. |
I would slightly prefer having dwp construction as an extra step to let the build system control the parallelism. I.e., don't always generate the dwp. I don't have a strong preference for either an emcc flag (or a trigger by filename) or a dwp tool in a well-defined location. The former is likely cleaner in CMake, for example, but not by a lot. |
I just filed emscripten-core/emsdk#720 to track the llvm-dwp bundling directly. |
I verified that |
This is technically a feature of LLVM rather than emscripten proper, but it's more convenient to track here.
LLVM currently supports
-gsplit-dwarf
for generating split dwarf files. Since we will likely end up using that, we should also make thellvm-dwp
tool work to "link" the.dwo
files together into a.dwp
file.The text was updated successfully, but these errors were encountered: