WebAssembly / WebAssembly/binaryen
Impossible address ranges in DWARF debug info
Nobody has claimed this yet.
- Dominant language
- WebAssembly
- Stars
- 8.6k
- Forks
- 885
- Avg merge
- 1d 19h
- Merged PRs (30d)
- 69
Description
I've been working on a tool that parses DWARF debug info embedded in WebAssembly binaries. The files I'm examining are optimized for size using wasm-opt -Oz -g. I've run into an issue where the address ranges of inlined subroutines will occasionally be impossibly large. Specifically, I'll find a DW_TAG_inlined_subroutine entry with a reasonable DW_AT_low_pc paired with a DW_AT_high_pc with a value of precisely 0x100000000. (Needless to say, the subroutine in question is not actually four gigabytes large.)
I encountered the issue on a bigger codebase, but I've narrowed it down to this simple program that reproduces the issue:
static void increment(int* array, int length) {
for (int i = 0; i < length; i++) {
array[i]++;
}
}
void _start(void) {
int array[2] = {0, 0};
increment(array, 2);
}
Compile and optimize like so:
$ clang bug.c -o bug.wasm -Oz -g --target=wasm32 -nostdlib
$ wasm-opt bug.wasm -o bug.wasm -Oz -g
The bug can be confirmed using llvm-dwarfdump:
$ llvm-dwarfdump bug.wasm --name increment
bug.wasm: file format WASM
0x00000022: DW_TAG_subprogram
DW_AT_name ("increment")
DW_AT_decl_file ("bug.c")
DW_AT_decl_line (1)
DW_AT_prototyped (true)
DW_AT_inline (DW_INL_inlined)
0x0000007c: DW_TAG_inlined_subroutine
DW_AT_abstract_origin (0x00000022 "increment")
DW_AT_low_pc (0x0000001a)
DW_AT_high_pc (0x100000000)
DW_AT_call_file ("bug.c")
DW_AT_call_line (9)
DW_AT_call_column (0x05)
I don't know the specific cause, but it only happens to code optimized by wasm-opt; clang's output is unaffected. It also only seems to affect DW_TAG_inlined_subroutine DIEs, from what I can tell.
Contributor guide
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
Reproduce the issue with the provided C program using clang and wasm-opt, then inspect the resulting DWARF with llvm-dwarfdump and compare it with clang's unaffected output. Trace Binaryen's wasm-opt DWARF handling for DW_TAG_inlined_subroutine entries; done means optimized output no longer reports an impossible DW_AT_high_pc of 0x100000000.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c, wasm
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100