-
Notifications
You must be signed in to change notification settings - Fork 191
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
Add DWARF debugging information to all artifacts by default #422
Conversation
This commit adds DWARF debugging information with the `-g` compiler flag to all WASI artifacts for wasi-sdk. The LLVM build itself does not have debugging information, only the sysroot artifacts. This is intended to assist with debugging. The main downside to this is binary size of generated artifacts will, by default, be larger. Stripping debug information from an artifact though involves removing custom sections which is generally pretty easy to do through wasm tooling.
Have you actually verified wasm modules can be debugged if the wasi-sdk installation path is different from the build path? The wasm objects dwarf sections contain absolute paths of their build path but does not embed the sources, I doubt if that can be useful at all if the user is not building wasi-sdk themselves. One example assembly source on godbolt. Even with |
Yes, I've verified this. My pre-existing install of wasi-sdk is at #include <stdio.h>
#include <stdlib.h>
int main() {
printf("%s\n", "hello");
abort();
} I get:
Note the lack of filename/line number in frame 0 and frame 2. With this PR:
Note the presence of That's a significant improvement for crashes in wasi-libc or other bugs relative to today. |
Ah thanks for the check! I also just figured out that something like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this makes a lot of sense, thanks! For those worried about binary size, it should be true that this additional DWARF information does not come along into the the final binary unless one opts in with -g
, right? (Of course, one can always just leave wasm-opt
in the PATH
to resolve that 😉).
I was about to merge this but:
- is the
wasi-libc
submodule update intentional? - we probably need to update some expected test output or something to make CI pass?
I think its the other way around, the linker (wasm-ld) will include debug info from any object files unless you link with |
Hm, well this change does seem in general "a good thing." Perhaps it's not too much to ask for users interested in small binaries to compile with extra flags or run |
Anyone shipping release binaries should always be stripping their binaries one way or another (either at link time, or post-link using Even without this change unstripped binaries contain a "name" section which can be pretty huge. |
* Update some expected error messages and remove some files with duplicate error messages that are no longer needed. * Remove undefined behavior in `stat.c` where padding bytes were being compared.
It is indeed! Sorry should have clarified but the update pulls in a few minor commit to fix build issues to ensure wasi-libc builds correctly.
I believe I've handled the test failures now. Some were just updating a few error messages but I had to also fix some undefined behavior in the Also yes thanks @sbc100 I forgot to mention but |
I forgot in WebAssembly#422 that by specifying `EXTRA_CFLAGS` to the wasi-libc build that it would override the defaults of wasi-libc which is to pass these two flags in. This passes them back in to ensure the default build still has the same flags.
I forgot in #422 that by specifying `EXTRA_CFLAGS` to the wasi-libc build that it would override the defaults of wasi-libc which is to pass these two flags in. This passes them back in to ensure the default build still has the same flags.
This commit adds DWARF debugging information with the
-g
compiler flag to all WASI artifacts for wasi-sdk. The LLVM build itself does not have debugging information, only the sysroot artifacts. This is intended to assist with debugging. The main downside to this is binary size of generated artifacts will, by default, be larger. Stripping debug information from an artifact though involves removing custom sections which is generally pretty easy to do through wasm tooling.