[PATCH] D66746: [LiveDebugValues] Omit entry values for DBG_VALUEs with pre-existing expressions

David Stenberg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 27 02:00:11 PDT 2019


dstenb added a comment.

In D66746#1645802 <https://reviews.llvm.org/D66746#1645802>, @vsk wrote:

> Thanks for the patch. Could you elaborate on what you mean by OP_entry_value only being able to wrap a single byte? Skimming the implementation, the impression I get is that a full machine-reg-expression can be attached to an OP_entry_value (see: DwarfCompileUnit::addComplexAddress).


The lang ref describes the DW_OP_entry_value operation in DIExpression as:

> If an expression is marked with DW_OP_entry_value all register and memory read operations refer to the respective value at the function entry. The first operand of DW_OP_entry_value is the size of following DWARF expression. DW_OP_entry_value may appear after the LiveDebugValues pass. LLVM only supports entry values for function parameters that are unmodified throughout a function and that are described as simple register location descriptions. DW_OP_entry_value may also appear after the AsmPrinter pass when a call site parameter value (DW_AT_call_site_parameter_value) is represented as entry value of the parameter.

I have interpreted the size as meaning the byte size of the DWARF block that the operation will cover. Assuming that, at the time of running LiveDebugValues I don't think there is a good way to query the size of the block that the entry value will cover; we don't know that until we actually emit the DWARF, as far as I can tell. That is why I have assumed that a hard coded operand of 1 is emitted there, with the assumption that only simple register location descriptions are supported.

However, I now got uncertain when looking at `prependOpcodes()` which is used to add the operation to the DIExpression:

  Ops.push_back(dwarf::DW_OP_entry_value);
  // Add size info needed for entry value expression.
  // Add plus one for target register operand.
  Ops.push_back(Expr->getNumElements() + 1);

As seen, there the number of pre-existing elements plus one is used. I don't think the number of elements does not map one-to-one with the byte size of the DWARF block, so I'm not sure how to interpret that. Can you help me understand what the operand in the DIExpression world indicates, @djtodoro?

As far as I understand, we now emit the operation from the DIExpression as-is in the DWARF. That means that if we have a register that turns into a complex expression we will still say that the size of that expression is one byte. I have seen such cases with our downstream target, but I'll see if I can trigger that behavior with an upstream target with a source level reproducer.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66746





More information about the llvm-commits mailing list