WebAssembly / WebAssembly/tool-conventions
Original Code Section Offset in Split DWARF Files
Nobody has claimed this yet.
- Dominant language
- WebAssembly
- Stars
- 372
- Forks
- 75
- PR merge metrics
- No merged PRs in 30d
Description
So since browsers report the absolute offset within a WASM file and do not have access to the code section offset, debugging tools that only operate on such offsets (such as Sentry or other crash reporting services) need to calculate the original offset. Right now we do this by forcing when split DWARF information is used (we use the proposed build_id #133 section to match the files, but the same issue arises when external_debug_info is used) to retain all original sections in the separate debug file including the Code section at the right offset.
There are three potential options here I see:
- Provide a
original_code_offsetsection with the offset of the original code section and embed that in split debug info files. - Change browser rendering (and suggest the same for runtimes) to not only report the absolute offset but also the code relative offset in stack traces.
- Add an API to access the code offset to the browser runtime so that the correct relative offset can be sent to crash reporting services.
Aside: In general I think there are some option questions about how this is supposed to work in practice. We're also running into issues in matching stack traces to the correct wasm files because of the limitations of the stack trace format. If one uses WebAssembly.instanciate with a buffer instead of WebAssembly.instanciateStreaming to load web assembly the stack trace format in browsers is completely inadequate to figure out which web assembly module a frame belongs to. As an alternative (if build_ids become an accepted format) it might be preferrable to add build ids and relative to build id offsets into the stack trace. Eg http://localhost:8088/lib1.wasm:wasm-function[1]:0x86 @ 483a64fa956ad1c848328c52f15dcc0bce1ca232+0x2) or something similar).
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No source file or test is identified. Start by comparing the three proposed approaches with the existing build_id and external_debug_info handling, then define the convention and its browser/runtime implications. Done requires an agreed, implementable way to recover original code offsets for split DWARF files.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- wasm
- Domain
- tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100