[PATCH] D101247: [Debug-Info] strict dwarf for DW_OP_stack_value

Mon May 10 13:54:17 PDT 2021

dblaikie added a comment.

In D101247#2747318 <https://reviews.llvm.org/D101247#2747318>, @shchenz wrote:

> In D101247#2717218 <https://reviews.llvm.org/D101247#2717218>, @dblaikie wrote:
>
>> I think this fix is too narrow/special-cased. Other places where expressions are emitted might use DW_OP_stack_value (check out all the test cases in llvm/test that mention DW_OP_stack_value - I think they're not only from global variables) - so probably the solution is to have some abstraction for emitting a DwarfExpression into a block for an attribute (if we don't have one already) and have that abstraction scan the operations to see if there's a DW_OP_stack_value, and if there is, the attribute would be skipped. Also refactoring any emission of expressions to ensure they all use such an abstraction so they go through a common codepath.
>
> Hi David @dblaikie , I did more investigation and still got the same conclusion in the description: it is hard to distinguish op `DW_OP_stack_value` from other unsigned values in location expression like offsets in the low-level/abstract API.
>
> and also since the users of `DW_OP_stack_value` are very scattered, do you think it is acceptable to just fix this special narrow case we met on AIX, current llvm code base already guards some usage of `DW_OP_stack_value` like in file `DwarfExpression.cpp`? Thanks.

Have you tried walking through an expression with the DIExpressionCursor? Like the code in `DwarfExpression::addExpression` which iterates a DIExpressionCursor  and is able to visit each operation without muddling up the operations from their operands. Maybe that or maybe some nearby/related APIs might be useful for this task.

Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101247/new/

https://reviews.llvm.org/D101247