Stream: git-wasmtime

Topic: wasmtime / issue #3656 Cranelift: unable to generate debu...

view this post on Zulip Wasmtime GitHub notifications bot (Jan 06 2022 at 14:52):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 06 2022 at 14:52):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 06 2022 at 14:52):

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.

view this post on Zulip Wasmtime GitHub notifications bot (Jan 06 2022 at 16:00):

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

view this post on Zulip Wasmtime GitHub notifications bot (Jan 06 2022 at 17:21):

fitzgen commented on issue #3656:

I don't have any particular insight here, sorry.

What does dwarfdump say about it?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 10 2022 at 14:49):

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?

view this post on Zulip Wasmtime GitHub notifications bot (Jan 10 2022 at 17:42):

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 the gimli repo. You could try running that (if it supports Wasm files, it might not) on this file as well and if the gimli version fails to parse the DWARF but the binutils version doesn't, then that's a strong hint that this is a bug in gimli.

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.

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2022 at 10:17):

bnjbvr commented on issue #3656:

Don't think we have seen this for a while, so closing.

view this post on Zulip Wasmtime GitHub notifications bot (May 06 2022 at 10:17):

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: Nov 22 2024 at 16:03 UTC