Skip to content
Please note that GitHub no longer supports Internet Explorer.

We recommend upgrading to the latest Microsoft Edge, Google Chrome, or Firefox.

Learn more
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

DWARF: Properly emit signed 32 bit values for advance_line #2625

Merged
merged 1 commit into from Jan 25, 2020
Merged

DWARF: Properly emit signed 32 bit values for advance_line #2625

merged 1 commit into from Jan 25, 2020

Conversation

@kripken
Copy link
Member

kripken commented Jan 24, 2020

The LLVM SData field is 64-bit (to support 64-bit
addresses I suppose) so when we assigned to it we
actually led it to emit an LEB for a signed 64-bit value
that is an unsigned 32-bit one. This worked in LLVM
(where I guess it forces the value to 32-bit anyhow?)
but failed in gimli (where I guess it doesn't?).

Found by @RReverser

…the 64-bit size in SData)
Copy link
Contributor

RReverser left a comment

Assuming this works (too bad we can't verify raw data with llvm-dwarfdump), LGTM.

@kripken

This comment has been minimized.

Copy link
Member Author

kripken commented Jan 24, 2020

I confirmed that with this PR, building with -gforce_dwarf emits DWARF info that loads ok in the debugger in Chrome dev (and breakpoints and stepping seem to work, but I didn't investigate closely yet).

@kripken kripken merged commit de18d96 into master Jan 25, 2020
4 checks passed
4 checks passed
continuous-integration/appveyor/branch AppVeyor build succeeded
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@kripken kripken deleted the s32 branch Jan 25, 2020
@billti

This comment has been minimized.

Copy link

billti commented Jan 30, 2020

@kripken I just attempted to emit DWARF for a simple program via the -gforce_dwarf flag and it crashed with the below. Let me know if this is a known issue, or if I should log and new one (and in which repo, as I'm unclear exactly which project is the root of this issue). I just yesterday confirmed emscripten, and emcc -v reports version 1.39.6.

C:\src\github\binview>emcc main.cpp --pre-js pre.js -o app.js -gforce_dwarf -fno-exceptions -fno-rtti -s ALLOW_MEMORY_GROWTH=1 -s "EXPORTED_FUNCTIONS=['_int_sqrt', '_getFileSize', '_readFile']" -s FILESYSTEM=0
shared:WARNING: gforce_dwarf is a temporary option that will eventually disappear
Assertion failed: DIE.getTag() != llvm::dwarf::DW_TAG_compile_unit && DIE.getTag() != llvm::dwarf::DW_TAG_subprogram, file C:\b\s\w\ir\cache\builder\emscripten-releases\binaryen\src\wasm\wasm-debug.cpp, line 511
shared:ERROR: 'C:/src/github/emsdk/upstream\bin\wasm-opt --post-emscripten --inline-main --no-exit-runtime --low-memory-unused --strip-producers --pass-arg=emscripten-sbrk-ptr@1696 app.wasm -o app.wasm -g --mvp-features' failed (-1073740791)
@kripken

This comment has been minimized.

Copy link
Member Author

kripken commented Jan 30, 2020

@billti That looks familiar, so it might be a bug that was fixed meanwhile. Please test with emsdk install tot (latest tip of tree build, which has fixes newer than 1.39.6). If it fails there please send me the testcase and I'll investigate.

@billti

This comment has been minimized.

Copy link

billti commented Jan 30, 2020

Not seeing an issue now. Thanks! I'll open up a new issue if I see any recurrence.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.