[all-commits] [llvm/llvm-project] 85460c: [DebugInfo] Do not emit entry values for composite...

[David via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 85460c4ea273784dd45da558ad9a6f13a79b2d91
      https://github.com/llvm/llvm-project/commit/85460c4ea273784dd45da558ad9a6f13a79b2d91
  Author: David Stenberg <david.stenberg at ericsson.com>
  Date:   2020-07-01 (Wed, 01 Jul 2020)

  Changed paths:
    M llvm/lib/CodeGen/AsmPrinter/DwarfExpression.cpp
    M llvm/lib/CodeGen/AsmPrinter/DwarfExpression.h
    M llvm/test/DebugInfo/Sparc/entry-value-complex-reg-expr.ll

  Log Message:
  -----------
  [DebugInfo] Do not emit entry values for composite locations

Summary:
This is a fix for PR45009.

When working on D67492 I made DwarfExpression emit a single
DW_OP_entry_value operation covering the whole composite location
description that is produced if a register does not have a valid DWARF
number, and is instead composed of multiple register pieces. Looking
closer at the standard, this appears to not be valid DWARF. A
DW_OP_entry_value operation's block can only be a DWARF expression or a
register location description, so it appears to not be valid for it to
hold a composite location description like that.

See DWARFv5 sec. 2.5.1.7:

"The DW_OP_entry_value operation pushes the value that the described
 location held upon entering the current subprogram. It has two
 operands: an unsigned LEB128 length, followed by a block containing a
 DWARF expression or a register location description (see Section
 2.6.1.1.3 on page 39)."

Here is a dwarf-discuss mail thread regarding this:

http://lists.dwarfstd.org/pipermail/dwarf-discuss-dwarfstd.org/2020-March/004610.html

There was not a strong consensus reached there, but people seem to lean
towards that operations specified under 2.6 (e.g. DW_OP_piece) may not
be part of a DWARF expression, and thus the DW_OP_entry_value operation
can't contain those.

Perhaps we instead want to emit a entry value operation per each
DW_OP_reg* operation, e.g.:

  - DW_OP_entry_value(DW_OP_regx sub_reg0),
    DW_OP_stack_value,
    DW_OP_piece 8,
  - DW_OP_entry_value(DW_OP_regx sub_reg1),
    DW_OP_stack_value,
    DW_OP_piece 8,
  [...]

The question then becomes how the call site should look; should a
composite location description be emitted there, and we then leave it up
to the debugger to match those two composite location descriptions?
Another alternative could be to emit a call site parameter entry for
each sub-register, but firstly I'm unsure if that is even valid DWARF,
and secondly it seems like that would complicate the collection of call
site values quite a bit. As far as I can tell GCC does not emit any
entry values / call sites in these cases, so we do not have something to
compare with, but the former seems like the more reasonable approach.

Currently when trying to emit a call site entry for a parameter composed
of multiple DWARF registers a (DwarfRegs.size() == 1) assert is
triggered in addMachineRegExpression(). Until the call site
representation is figured out, and until there is use for these entry
values in practice, this commit simply stops the invalid DWARF from
being emitted.

Reviewers: djtodoro, vsk, aprantl

Reviewed By: djtodoro, vsk

Subscribers: jyknight, hiraditya, fedor.sergeev, jrtc27, llvm-commits

Tags: #debug-info, #llvm

Differential Revision: https://reviews.llvm.org/D75270