Stream: git-wasmtime

Topic: wasmtime / Issue #2565 Draft: detailed debug-info (DWARF)...

Wasmtime GitHub notifications bot (Jan 09 2021 at 10:57):

cfallin commented on Issue #2565:

@yurydelendik, I think I will need your help on this -- it appears that you wrote all of the debug support initially? Two questions:

1. Is there a reason that the gdb tests are currently marked #[ignore]? Are they known to be broken for other reasons?

2. If not, would you be able to help me debug this? I believe the analysis is generating correct, or mostly correct, mappings of labels to registers; but the debug crate in wasmtime is generating DWARF that uses the vmctx register outside of its valid range and I don't understand enough about DWARF or the code here to say why.

Any help from anyone who is passionate about debuginfo would be appreciated -- this is one of the last pieces needed to enable the switch to the new backend by default in wasmtime, and I've dumped a bunch of time into this and need to context-switch for a little bit :-)

Wasmtime GitHub notifications bot (Jan 09 2021 at 19:38):

yurydelendik commented on Issue #2565:

Is there a reason that the gdb tests are currently marked #[ignore]? Are they known to be broken for other reasons?

They are marked as "ignored" to not run them on developer's computer: the tests require lldb/gdb/llvm-dwarfdump install. These tests are run on the CI. See https://github.com/bytecodealliance/wasmtime/blob/cacebfb19c721b293c947f9bc8c57643c2763b95/.github/workflows/main.yml#L287-L293

If not, would you be able to help me debug this?

I'll try to be useful, yes.

but the debug crate in wasmtime is generating DWARF that uses the vmctx register outside of its valid range

To keep vmctx register/value valid as long as possible is a desired functionality, as well as knowing it during stack unwinding to provide Instance information. We talked with @sunfishcode about having fixed location for vmctx some time back.

If vmctx is not available, there is no way to get a variable value stored in the instances memory and shadow stack. The variables are marked as optimized out in this case. Which is acceptable solution from debugging of optimized code point of view. Of course we have to minimize such cases to make live of developers better.

Wasmtime GitHub notifications bot (Jan 09 2021 at 20:46):

cfallin commented on Issue #2565:

To keep vmctx register/value valid as long as possible is a desired functionality, as well as knowing it during stack unwinding to provide Instance information. We talked with @sunfishcode about having fixed location for vmctx some time back.

If vmctx is not available, there is no way to get a variable value stored in the instances memory and shadow stack. The variables are marked as optimized out in this case. Which is acceptable solution from debugging of optimized code point of view. Of course we have to minimize such cases to make live of developers better.

Makes sense; I'll think about ways to do this. Perhaps the simplest would be to just add a hack that emits a value_label psuedo-instruction for vmctx at return -- this would keep it alive and ensure it can be accessed at least from a spillslot if not a register.

A question: I was struggling to work out the invariants in the code that converts range-associated data. What do start and end denote for the ValueLabelsRanges? Are these open or closed bounds and do they apply to the start or end of instructions? I had noticed some code that skips any "empty" ranges (start == end) -- if a value is computable only after one instruction, which ends at offset X, should we encode that as start=X, end=X+1?

There's something a little more broken going on in this PR right now, as the vmctx value is dead at a certain point, but DWARF info related to its former register is being generated. So I suspect that I'm misunderstanding some of the invariants related to ranges.

Thanks for the help!

Last updated: Dec 23 2024 at 13:07 UTC