[PATCH] D59687: [DebugInfo] Prologue inserter need to insert DW_OP_deref_size

Markus Lavin via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Mar 26 02:00:36 PDT 2019


markus added a comment.

Again (and sorry for possibly over emphasizing this) the purpose of this patch is that a `DW_OP_deref` needs to be inserted before a `memory location description` can be prepended to an already existing `implicit location description` as otherwise the latter expression would act on the former address and not the actual value in memory.

The reasoning behind the `DW_OP_deref_size` is probably best explained with an example. Consider a machine with 32 bit addresses and assume that our location description referes to a 8 bit value (so that is really the size of the value we want to load).

- If our machine is little endian then a `DW_OP_deref` from address `A` will load (from most significant to least significant byte) `{A[3],A[2],A[1],A[0]}` onto the stack. If we truncate this 32 bit value to 8 bits then we are left with `{A[0]}` which exactly corresponds to a 8 bit value at address `A`, so no problem here.
- On the other hand if our machine is big endian then a `DW_OP_deref` from address `A` will load (from most significant to least significant byte) `{A[0],A[1],A[2],A[3]}` onto the stack. If we truncate this 32 bit value to 8 bits then we are left with `{A[3]}` which is clearly not the 8 bit value at address `A`.

So for big endian we need to load the right size from the start.



================
Comment at: test/CodeGen/X86/prologepilog_deref_size.mir:58
+# CHECK: machineFunctionInfo
+# CHECK: DIExpression(DW_OP_plus_uconst, {{[0-9]+}}, DW_OP_deref_size, 2, DW_OP_LLVM_convert, 16, DW_ATE_unsigned, DW_OP_LLVM_convert, 32, DW_ATE_unsigned, DW_OP_stack_value)
----------------
probinson wrote:
> Not sure I follow the purpose of these conversions. DW_OP_deref_size is specified to zero-extend the fetched bytes to the size of an address. The convert operators look like they are just doing the same thing over again?
Yes, perhaps this example is a bit ill formed in that sense and would be better of performing `sext` instead of `zext` so that the `DW_OP_convert` ops actually did something useful. I will change that.



Repository:
  rL LLVM

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

https://reviews.llvm.org/D59687





More information about the llvm-commits mailing list