DWARFExpression implements the DWARF2 expression model that left ambiguity on whether the result of an expression was a value or an address. This patch implements the DWARF location description model introduces in DWARF 4 and sets the result Value's kind accordingly, if the expression comes from a DWARF v4+ compile unit. The nomenclature is taken from DWARF 5, chapter 2.6 "Location Descriptions".
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
(idle question: Is this code remotely related to any code in LLVM's libDebugInfoDWARF? Does this patch take us closer to or further away from unifying them? If it takes us further away, any chance of designing it in a direction that points towards each other rather than away from?)
Are you sure that this logic is correct in presence of DW_OP(_bit)_piece? If I follow this right, then the final value type will be determined by the last operand. That sounds like it could be right for regular dwarf expressions, but I'm not sure about those with pieces. The classification function will mark those as "memory", and that doesn't sound right...
lldb/unittests/Expression/DWARFExpressionTest.cpp | ||
---|---|---|
360–361 | This comment doesn't seem right. |
lldb/source/Expression/DWARFExpression.cpp | ||
---|---|---|
1009 | That also makes it more explicit that this is updating the dwarf4_location_description_kind | |
1038 | Could you return the kind and do LocationDescriptionKind dwarf4_location_description_kind = classifyLocationDescription? That way you can make it a static instead of a lambda in a function that's already a hundreds of lines long. | |
2664 | lldb_assert? |
@dblaikie wrote:
(idle question: Is this code remotely related to any code in LLVM's libDebugInfoDWARF? Does this patch take us closer to or further away from unifying them? If it takes us further away, any chance of designing it in a direction that points towards each other rather than away from?)
There's definitely an opportunity to refactor the main loop of Evaluate() to use llvm::DWARFExpression::iterator. I would say The impact of this patch towards that goal is neutral. The iterator (and all of libDebugInfo) doesn't care about the semantics of DWARF expressions.
lldb/source/Expression/DWARFExpression.cpp | ||
---|---|---|
2643 | @labath wrote:
DW_OP_pieces are handled in this block. For your immediate question, this means that this patch is safe. However, it also highlights that this patch isn't fixing the same bug in a composite location description. I'll address this in my next revision of the patch. |
Updated the patch to compute the classification on the fly and take composition operators into account.
That also makes it more explicit that this is updating the dwarf4_location_description_kind