Skip to content
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

Closed
dschuff opened this issue Jan 13, 2021 · 12 comments
Closed

Support DWP files #13251

dschuff opened this issue Jan 13, 2021 · 12 comments

Comments

@dschuff
Copy link
Member

dschuff commented Jan 13, 2021

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 the llvm-dwp tool work to "link" the .dwo files together into a .dwp file.

@pfaffe
Copy link
Collaborator

pfaffe commented Jan 14, 2021

I submitted https://reviews.llvm.org/D93749 to make llvm-dwp also generate wasm files.

@dschuff
Copy link
Member Author

dschuff commented Jan 14, 2021

Oh, great! You don't need me to land that for you, correct?

@pfaffe
Copy link
Collaborator

pfaffe commented Jan 25, 2021

Landed!

@dschuff
Copy link
Member Author

dschuff commented Jan 25, 2021

Are there more known issues with DWP generation for wasm?

@pfaffe
Copy link
Collaborator

pfaffe commented Jan 26, 2021

Not that I know of. What's still missing is making llvm-dwp available through emscripten.

@pfaffe
Copy link
Collaborator

pfaffe commented Jan 26, 2021

There is still the open issue of WebAssembly/binaryen#3506. Split-dwarf and binaryen can't work together.

@dschuff
Copy link
Member Author

dschuff commented Jan 26, 2021

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

@pfaffe
Copy link
Collaborator

pfaffe commented Jan 26, 2021

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!

@dschuff
Copy link
Member Author

dschuff commented Jan 26, 2021

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.

@pfaffe
Copy link
Collaborator

pfaffe commented Jan 28, 2021

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.

@pfaffe
Copy link
Collaborator

pfaffe commented Feb 19, 2021

I just filed emscripten-core/emsdk#720 to track the llvm-dwp bundling directly.

@pfaffe
Copy link
Collaborator

pfaffe commented Feb 22, 2021

I verified that llvm-dwp is shipped in tot, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants