[DWARF] Inheritance DW_TAGs dropped by GC
#9828
Comments
SingleAccretion
changed the title
DW_TAGs dropped by GCDW_TAGs dropped by GC
SingleAccretion
added a commit
to SingleAccretion/runtimelab
that referenced
this issue
Dec 16, 2024
So far, we have been emitting type definitions into each compile unit where they were 'used'. This proved problematic (wrong) as the debugger does not "unify" types across compile units - they are expected to be the same, due to ODR. To solve this fundamental issue, this change introduces a more elaborate emission scheme, where during compilation only type forwards are emitted, which will later get satisfied by types defined in one big DI module. While the fundamental idea is sound, the implementation is constrained by the lack of direct support for DW_FORM_ref_addr references in LLVM. Ideally, we would use those to refer to types in the debug module directly, however, in the absence of this, forward declarations have to do. One problem with forward declarations that had to be worked around was wasmtime's DI GC, which only resolves DWARF's 'reference's. Thus, our types need manual 'rooting', which is accomplished in this change by emitting a dummy retained subroutine that references all of them. With these changes, as well as some fixes in wasmtime (especially bytecodealliance/wasmtime#9828), the expanded LLDB (finally) test passes.
SingleAccretion
added a commit
to SingleAccretion/runtimelab
that referenced
this issue
Dec 16, 2024
So far, we have been emitting type definitions into each compile unit where they were 'used'. This proved problematic (wrong) as the debugger does not "unify" types across compile units - they are expected to be the same, due to ODR. To solve this fundamental issue, this change introduces a more elaborate emission scheme, where during compilation only type forwards are emitted, which will later get satisfied by types defined in one big DI module. While the fundamental idea is sound, the implementation is constrained by the lack of direct support for DW_FORM_ref_addr references in LLVM. Ideally, we would use those to refer to types in the debug module directly, however, in the absence of this, forward declarations have to do. One problem with forward declarations that had to be worked around was wasmtime's DI GC, which only resolves DWARF's 'reference's. Thus, our types need manual 'rooting', which is accomplished in this change by emitting a dummy retained subroutine that references all of them. With these changes, as well as some fixes in wasmtime (especially bytecodealliance/wasmtime#9828), the expanded LLDB (finally) test passes.
SingleAccretion
added a commit
to SingleAccretion/runtimelab
that referenced
this issue
Dec 16, 2024
So far, we have been emitting type definitions into each compile unit where they were 'used'. This proved problematic (wrong) as the debugger does not "unify" types across compile units - they are expected to be the same, due to ODR. To solve this fundamental issue, this change introduces a more elaborate emission scheme, where during compilation only type forwards are emitted, which will later get satisfied by types defined in one big DI module. While the fundamental idea is sound, the implementation is constrained by the lack of direct support for DW_FORM_ref_addr references in LLVM. Ideally, we would use those to refer to types in the debug module directly, however, in the absence of this, forward declarations have to do. One problem with forward declarations that had to be worked around was wasmtime's DI GC, which only resolves DWARF's 'reference's. Thus, our types need manual 'rooting', which is accomplished in this change by emitting a dummy retained subroutine that references all of them. With these changes, as well as some fixes in wasmtime (especially bytecodealliance/wasmtime#9828), the expanded LLDB (finally) test passes.
SingleAccretion
added a commit
to SingleAccretion/runtimelab
that referenced
this issue
Dec 17, 2024
So far, we have been emitting type definitions into each compile unit where they were 'used'. This proved problematic (wrong) as the debugger does not "unify" types across compile units - they are expected to be the same, due to ODR. To solve this fundamental issue, this change introduces a more elaborate emission scheme, where during compilation only type forwards are emitted, which will later get satisfied by types defined in one big DI module. While the fundamental idea is sound, the implementation is constrained by the lack of direct support for DW_FORM_ref_addr references in LLVM. Ideally, we would use those to refer to types in the debug module directly, however, in the absence of this, forward declarations have to do. One problem with forward declarations that had to be worked around was wasmtime's DI GC, which only resolves DWARF's 'reference's. Thus, our types need manual 'rooting', which is accomplished in this change by emitting a dummy retained subroutine that references all of them. With these changes, as well as some fixes in wasmtime (especially bytecodealliance/wasmtime#9828), the expanded LLDB (finally) test passes.
SingleAccretion
added a commit
to SingleAccretion/runtimelab
that referenced
this issue
Dec 18, 2024
So far, we have been emitting type definitions into each compile unit where they were 'used'. This proved problematic (wrong) as the debugger does not "unify" types across compile units - they are expected to be the same, due to ODR. To solve this fundamental issue, this change introduces a more elaborate emission scheme, where during compilation only type forwards are emitted, which will later get satisfied by types defined in one big DI module. While the fundamental idea is sound, the implementation is constrained by the lack of direct support for DW_FORM_ref_addr references in LLVM. Ideally, we would use those to refer to types in the debug module directly, however, in the absence of this, forward declarations have to do. One problem with forward declarations that had to be worked around was wasmtime's DI GC, which only resolves DWARF's 'reference's. Thus, our types need manual 'rooting', which is accomplished in this change by emitting a dummy retained subroutine that references all of them. With these changes, as well as some fixes in wasmtime (especially bytecodealliance/wasmtime#9828), the expanded LLDB (finally) test passes.
jkotas
pushed a commit
to dotnet/runtimelab
that referenced
this issue
Dec 30, 2024
* Fill out the test * Overhaul debug info generation So far, we have been emitting type definitions into each compile unit where they were 'used'. This proved problematic (wrong) as the debugger does not "unify" types across compile units - they are expected to be the same, due to ODR. To solve this fundamental issue, this change introduces a more elaborate emission scheme, where during compilation only type forwards are emitted, which will later get satisfied by types defined in one big DI module. While the fundamental idea is sound, the implementation is constrained by the lack of direct support for DW_FORM_ref_addr references in LLVM. Ideally, we would use those to refer to types in the debug module directly, however, in the absence of this, forward declarations have to do. One problem with forward declarations that had to be worked around was wasmtime's DI GC, which only resolves DWARF's 'reference's. Thus, our types need manual 'rooting', which is accomplished in this change by emitting a dummy retained subroutine that references all of them. With these changes, as well as some fixes in wasmtime (especially bytecodealliance/wasmtime#9828), the expanded LLDB (finally) test passes. * Use daily wasmtime
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Reproduction:
1) Compile the following C++ to WASM with
-g:2) Run under wasmtime+LLDB:
Expected result:
Actual result:
Cause: DI GC drops correctness-bearing
DW_TAG_inheritanceDIEs.Fix incoming...
The text was updated successfully, but these errors were encountered: