WebAssembly / WebAssembly/tool-conventions

Original Code Section Offset in Split DWARF Files

Open
#155 2 comments 2 reactions 0 assignees View on GitHub

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:

  1. Provide a original_code_offset section with the offset of the original code section and embed that in split debug info files.
  2. 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.
  3. 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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.