[PATCH] D67556: [ARM][AArch64][DebugInfo] Improve call site instruction interpretation

David Stenberg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 16 05:42:26 PDT 2019


dstenb added a comment.
Herald added a subscriber: dmgreen.

In general, is it really safe to describe loaded values at the call sites?

For example, consider the following program:

caller.c:

  #include <stdint.h>
  
  extern int callee(uint64_t);
  extern void escape(uint64_t *);
  
  uint64_t value = 0x1234;
  
  int main() {
    uint64_t local = value;
    escape(&local);
    callee(local);
    return 0;
  }

callee.c:

  #include <stdint.h>
  
  extern void clobber(void);
  
  static uint64_t *ptr;
  
  void escape(uint64_t *p) {
    ptr = p;
  }
  
  int callee(uint64_t p) {
    *ptr = 0xdead;
    clobber();
    // Print parameter here.
    return 0;
  }

compiled using `-O3 -g -Xclang -femit-debug-entry-values --target=aarch64` results in the following call site entry for `callee`'s parameter:

  0x000000cf:       DW_TAG_GNU_call_site_parameter
                      DW_AT_location	(DW_OP_reg0 W0)
                      DW_AT_GNU_call_site_value	(DW_OP_breg31 WSP+1, DW_OP_deref)

In this case it seems that the parameter would be printed incorrectly due to deref'ing `local`, which has been modified after the call to `callee` began? I unfortunately don't have any ARM machine/qemu up and running, so I can't verify this.

(A side-comment, but shouldn't the offset be 8 here? The value corresponds to a `ldr x0, [sp, #8]`.)

I think that the same concern holds about the `MI.hasOneMemOperand()` part of TargetInstrInfo's implementation of `describeLoadedValue()`.

The DWARF standard (Sec. 3.4.2) states that call site values should be omitted if they may be clobbered by the call:

> If it is not possible to avoid registers or memory locations that might be clobbered by the call in the expression, then the DW_AT_call_value attribute should not be provided. The reason for the restriction is that the value of the parameter may be needed in the midst of the callee, where the call clobbered registers or memory might be already clobbered, and if the consumer is not assured by the producer it can safely use those values, the consumer can not safely use the values at all.

Or am I overlooking something here?



================
Comment at: include/llvm/CodeGen/TargetInstrInfo.h:891
+  /// added.
+  virtual bool isAddImmidiate(const MachineInstr &MI,
+                              const MachineOperand *&Source,
----------------
spelling: Immediate


================
Comment at: lib/Target/ARM/ARMBaseInstrInfo.cpp:5327
+
+  // We desciribe SUBri or ADDri instructions.
+  if (Opcode == ARM::SUBri)
----------------
nit: describe


================
Comment at: lib/Target/ARM/ARMBaseInstrInfo.cpp:5348
+  if (MI.getOpcode() == ARM::LDRi12) {
+    //TODO: Loaded value could aslo be constant pool index. For now we are
+    //      not able to use such description at dwarf generating backend.
----------------
nit: also


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

https://reviews.llvm.org/D67556





More information about the llvm-commits mailing list