cfallin opened PR #2565 from debug-value-labels
to main
:
This PR is an initial attempt at propagating "value labels" all the way
from CLIF to DWARF metadata on the emitted machine code. The key idea is
as follows:
Translate value-label metadata on the input into "value_label"
pseudo-instructions when lowering into VCode. These
pseudo-instructions take a register as input, denote a value label,
and semantically are like a "move into value label" -- i.e., they
update the current value (as seen by debugging tools) of the given
local. These pseudo-instructions emit no machine code.Perform a dataflow analysis at the machine-code level, tracking
value-labels that propagate into registers and into [SP+constant]
stack storage. This is a forward dataflow fixpoint analysis where each
storage location can contain a set of value labels, and each value
label can reside in a set of storage locations. (Meet function is
pairwise intersection by storage location.)This analysis traces value labels symbolically through loads and
stores and reg-to-reg moves, so it will naturally handle spills and
reloads without knowing anything special about them.When this analysis converges, we have, at each machine-code offset, a
mapping from value labels to some number of storage locations; for
each offset for each label, we choose the best location (prefer
registers). Note that we can choose any location, as the symbolic
dataflow analysis is sound and guarantees that the value at the
value_label instruction propagates to all of the named locations.Then we can convert this mapping into a format that the DWARF
generation code (wasmtime's debug crate) can use.Unfortunately, it doesn't quite work yet with the gdb tests in
tests/all/debug/gdb.rs. Strangely, these tests are marked#[ignore]
.
Needs more debugging, I'd like to publish this draft now as-is to share
the design and get feedback / bringup help on the tests.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
cfallin requested yurydelendik for a review on PR #2565.
cfallin updated PR #2565 from debug-value-labels
to main
:
This PR is an initial attempt at propagating "value labels" all the way
from CLIF to DWARF metadata on the emitted machine code. The key idea is
as follows:
Translate value-label metadata on the input into "value_label"
pseudo-instructions when lowering into VCode. These
pseudo-instructions take a register as input, denote a value label,
and semantically are like a "move into value label" -- i.e., they
update the current value (as seen by debugging tools) of the given
local. These pseudo-instructions emit no machine code.Perform a dataflow analysis at the machine-code level, tracking
value-labels that propagate into registers and into [SP+constant]
stack storage. This is a forward dataflow fixpoint analysis where each
storage location can contain a set of value labels, and each value
label can reside in a set of storage locations. (Meet function is
pairwise intersection by storage location.)This analysis traces value labels symbolically through loads and
stores and reg-to-reg moves, so it will naturally handle spills and
reloads without knowing anything special about them.When this analysis converges, we have, at each machine-code offset, a
mapping from value labels to some number of storage locations; for
each offset for each label, we choose the best location (prefer
registers). Note that we can choose any location, as the symbolic
dataflow analysis is sound and guarantees that the value at the
value_label instruction propagates to all of the named locations.Then we can convert this mapping into a format that the DWARF
generation code (wasmtime's debug crate) can use.Unfortunately, it doesn't quite work yet with the gdb tests in
tests/all/debug/gdb.rs. Strangely, these tests are marked#[ignore]
.
Needs more debugging, I'd like to publish this draft now as-is to share
the design and get feedback / bringup help on the tests.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
cfallin updated PR #2565 from debug-value-labels
to main
:
This PR is an initial attempt at propagating "value labels" all the way
from CLIF to DWARF metadata on the emitted machine code. The key idea is
as follows:
Translate value-label metadata on the input into "value_label"
pseudo-instructions when lowering into VCode. These
pseudo-instructions take a register as input, denote a value label,
and semantically are like a "move into value label" -- i.e., they
update the current value (as seen by debugging tools) of the given
local. These pseudo-instructions emit no machine code.Perform a dataflow analysis at the machine-code level, tracking
value-labels that propagate into registers and into [SP+constant]
stack storage. This is a forward dataflow fixpoint analysis where each
storage location can contain a set of value labels, and each value
label can reside in a set of storage locations. (Meet function is
pairwise intersection by storage location.)This analysis traces value labels symbolically through loads and
stores and reg-to-reg moves, so it will naturally handle spills and
reloads without knowing anything special about them.When this analysis converges, we have, at each machine-code offset, a
mapping from value labels to some number of storage locations; for
each offset for each label, we choose the best location (prefer
registers). Note that we can choose any location, as the symbolic
dataflow analysis is sound and guarantees that the value at the
value_label instruction propagates to all of the named locations.Then we can convert this mapping into a format that the DWARF
generation code (wasmtime's debug crate) can use.Unfortunately, it doesn't quite work yet with the gdb tests in
tests/all/debug/gdb.rs. Strangely, these tests are marked#[ignore]
.
Needs more debugging, I'd like to publish this draft now as-is to share
the design and get feedback / bringup help on the tests.<!--
Please ensure that the following steps are all taken care of before submitting
the PR.
[ ] This has been discussed in issue #..., or if not, please tell us why
here.[ ] A short description of what this does, why it is needed; if the
description becomes long, the matter should probably be discussed in an issue
first.[ ] This PR contains test cases, if meaningful.
- [ ] A reviewer from the core maintainer team has been assigned for this PR.
If you don't know who could review this, please indicate so. The list of
suggested reviewers on the right can help you.Please ensure all communication adheres to the code of conduct.
-->
cfallin edited PR #2565 from debug-value-labels
to main
:
This PR propagates "value labels" all the way from CLIF to DWARF
metadata on the emitted machine code. The key idea is as follows:
Translate value-label metadata on the input into "value_label"
pseudo-instructions when lowering into VCode. These
pseudo-instructions take a register as input, denote a value label,
and semantically are like a "move into value label" -- i.e., they
update the current value (as seen by debugging tools) of the given
local. These pseudo-instructions emit no machine code.Perform a dataflow analysis at the machine-code level, tracking
value-labels that propagate into registers and into [SP+constant]
stack storage. This is a forward dataflow fixpoint analysis where each
storage location can contain a set of value labels, and each value
label can reside in a set of storage locations. (Meet function is
pairwise intersection by storage location.)This analysis traces value labels symbolically through loads and
stores and reg-to-reg moves, so it will naturally handle spills and
reloads without knowing anything special about them.When this analysis converges, we have, at each machine-code offset, a
mapping from value labels to some number of storage locations; for
each offset for each label, we choose the best location (prefer
registers). Note that we can choose any location, as the symbolic
dataflow analysis is sound and guarantees that the value at the
value_label instruction propagates to all of the named locations.Then we can convert this mapping into a format that the DWARF
generation code (wasmtime's debug crate) can use.This PR also adds the new-backend variant to the gdb tests on CI.
Last updated: Nov 22 2024 at 16:03 UTC