bnjbvr labeled issue #3656:
We have a wasm module that's been compiled with Rustc on Windows, and enabling debug information generation when running it in wasmtime causes the following error:
failed to emit DWARF debug information -> Unexpected attribute: Block(EndianSlice { slice: [123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], endian: LittleEndian })
I don't know much about DWARF in general, but a quick search in the DWARF 5 specification says 123 == 0x7b is the binary encoding of the
DW_AT_call_all_source_calls
attribute, which documentation says that:The DW_AT_call_all_source_calls attribute indicates that every call that occurs in the code for the subprogram, including every call inlined into it, is described by either a DW_TAG_call_site entry or a DW_TAG_inlined_subroutine entry; further, any call that is optimized out is nonetheless also described using a DW_TAG_call_site entry that has neither a DW_AT_call_pc nor DW_AT_call_return_pc attribute. The DW_AT_call_all_source_calls attribute is intended for debugging information format consumers that analyze call graphs. If the the DW_AT_call_all_source_calls attribute is present then the DW_AT_call_all_calls and DW_AT_call_all_tail_calls attributes are also implicitly present.
(The fact that gimli parses the data as a Block suggests something goes wrong before it even recognizes this is an attribute, but I can't tell for sure.)
I can't reproduce the issue when compiling from the same commit, with the same version of Rustc, on Linux, so I suspect there is some platform-specific DWARF encoding in there.
cc @fitzgen @yurydelendik in case you have any ideas, or hints towards how I could help debug this further.
bnjbvr opened issue #3656:
We have a wasm module that's been compiled with Rustc on Windows, and enabling debug information generation when running it in wasmtime causes the following error:
failed to emit DWARF debug information -> Unexpected attribute: Block(EndianSlice { slice: [123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], endian: LittleEndian })
I don't know much about DWARF in general, but a quick search in the DWARF 5 specification says 123 == 0x7b is the binary encoding of the
DW_AT_call_all_source_calls
attribute, which documentation says that:The DW_AT_call_all_source_calls attribute indicates that every call that occurs in the code for the subprogram, including every call inlined into it, is described by either a DW_TAG_call_site entry or a DW_TAG_inlined_subroutine entry; further, any call that is optimized out is nonetheless also described using a DW_TAG_call_site entry that has neither a DW_AT_call_pc nor DW_AT_call_return_pc attribute. The DW_AT_call_all_source_calls attribute is intended for debugging information format consumers that analyze call graphs. If the the DW_AT_call_all_source_calls attribute is present then the DW_AT_call_all_calls and DW_AT_call_all_tail_calls attributes are also implicitly present.
(The fact that gimli parses the data as a Block suggests something goes wrong before it even recognizes this is an attribute, but I can't tell for sure.)
I can't reproduce the issue when compiling from the same commit, with the same version of Rustc, on Linux, so I suspect there is some platform-specific DWARF encoding in there.
cc @fitzgen @yurydelendik in case you have any ideas, or hints towards how I could help debug this further.
bnjbvr labeled issue #3656:
We have a wasm module that's been compiled with Rustc on Windows, and enabling debug information generation when running it in wasmtime causes the following error:
failed to emit DWARF debug information -> Unexpected attribute: Block(EndianSlice { slice: [123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], endian: LittleEndian })
I don't know much about DWARF in general, but a quick search in the DWARF 5 specification says 123 == 0x7b is the binary encoding of the
DW_AT_call_all_source_calls
attribute, which documentation says that:The DW_AT_call_all_source_calls attribute indicates that every call that occurs in the code for the subprogram, including every call inlined into it, is described by either a DW_TAG_call_site entry or a DW_TAG_inlined_subroutine entry; further, any call that is optimized out is nonetheless also described using a DW_TAG_call_site entry that has neither a DW_AT_call_pc nor DW_AT_call_return_pc attribute. The DW_AT_call_all_source_calls attribute is intended for debugging information format consumers that analyze call graphs. If the the DW_AT_call_all_source_calls attribute is present then the DW_AT_call_all_calls and DW_AT_call_all_tail_calls attributes are also implicitly present.
(The fact that gimli parses the data as a Block suggests something goes wrong before it even recognizes this is an attribute, but I can't tell for sure.)
I can't reproduce the issue when compiling from the same commit, with the same version of Rustc, on Linux, so I suspect there is some platform-specific DWARF encoding in there.
cc @fitzgen @yurydelendik in case you have any ideas, or hints towards how I could help debug this further.
bjorn3 commented on issue #3656:
According to the source it should be parsed as flag: https://github.com/gimli-rs/gimli/blob/ef97809efe9adeda039c5f5397480522d25cebaa/src/read/unit.rs#L1675-L1677
fitzgen commented on issue #3656:
I don't have any particular insight here, sorry.
What does
dwarfdump
say about it?
bnjbvr commented on issue #3656:
What does dwarfdump say about it?
Ah thanks, didn't know this tool. It does generate a 200 MB file for this particular wasm module. Is there something in particular I should look for?
fitzgen commented on issue #3656:
I guess I was curious whether it parsed okay with
dwarfdump
. Can you see the relevant attribute in the output?There is also a
dwarfdump
clone in thegimli
repo. You could try running that (if it supports Wasm files, it might not) on this file as well and if thegimli
version fails to parse the DWARF but the binutils version doesn't, then that's a strong hint that this is a bug ingimli
.But yeah, this is pretty hard to debug without being able to create a smaller test case. You could try running
wasm-tools shrink
on it (from https://github.com/bytecodealliance/wasm-tools) but it will just shrink the Wasm bits and not the DWARF bits because we haven't added mutators for custom sections yet.
bnjbvr commented on issue #3656:
Don't think we have seen this for a while, so closing.
bnjbvr closed issue #3656:
We have a wasm module that's been compiled with Rustc on Windows, and enabling debug information generation when running it in wasmtime causes the following error:
failed to emit DWARF debug information -> Unexpected attribute: Block(EndianSlice { slice: [123, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0], endian: LittleEndian })
I don't know much about DWARF in general, but a quick search in the DWARF 5 specification says 123 == 0x7b is the binary encoding of the
DW_AT_call_all_source_calls
attribute, which documentation says that:The DW_AT_call_all_source_calls attribute indicates that every call that occurs in the code for the subprogram, including every call inlined into it, is described by either a DW_TAG_call_site entry or a DW_TAG_inlined_subroutine entry; further, any call that is optimized out is nonetheless also described using a DW_TAG_call_site entry that has neither a DW_AT_call_pc nor DW_AT_call_return_pc attribute. The DW_AT_call_all_source_calls attribute is intended for debugging information format consumers that analyze call graphs. If the the DW_AT_call_all_source_calls attribute is present then the DW_AT_call_all_calls and DW_AT_call_all_tail_calls attributes are also implicitly present.
(The fact that gimli parses the data as a Block suggests something goes wrong before it even recognizes this is an attribute, but I can't tell for sure.)
I can't reproduce the issue when compiling from the same commit, with the same version of Rustc, on Linux, so I suspect there is some platform-specific DWARF encoding in there.
cc @fitzgen @yurydelendik in case you have any ideas, or hints towards how I could help debug this further.
Last updated: Dec 23 2024 at 13:07 UTC