Closed sevaa closed 1 year ago
Hmm, I'm also not sure how this gets into pyelftools at all, since WASM binaries aren't ELF. How are you even testing this?
I have no way to test this. What I have is a crash report, telling me that DWEX threw an exception on a user's machine: KeyError in parse_expr() on dwarf_expr.py:151 with key 237 (0xED). That line goes:
arg_parser = self._dispatch_table[op]
The whole expression blob goes [237, 2, 1, 159]. That's pretty much all I have. There are some contrived scenarios how this could be bogus - something was interpreted as a location that shouldn't be. But the most likely scenario is that this is indeed a two op expression, opcode 0xED with a two byte argument block followed by DW_OP_stack_value
. The argument structure of 0xED is consistent with the linked docs. Modulo the first op, this is a rather vanilla DWARF expression.
FYI, pyelftools can be and is used to parse DWARF in non-ELF binaries. DWEX does that. However, DWEX doesn't support WASM binaries (hehe, maybe it should), and the crash report was specifically from DWEX, not from pyelftools in come other context.
DWEX doesn't support WASM binaries
EDIT: it does now.
OK, thanks for the additional background
Another day, another crash report on my end about a vendor DWARF extension.
This one is documented at least: https://yurydelendik.github.io/webassembly-dwarf/ section 2.2
On a second look, WASM has its own executable binary format that DWEX doesn't support. I'm not sure how did DWARF opcode 0xED make it into an ELF/PE/MachO binary. Barring the potential case of a corrupted/misparsed expression blob, in theory it could be some other vendor extension with opcode 0xED.