[PATCH] D56587: Fix sign/zero extension in Dwarf expressions.

[Markus Lavin via Phabricator via llvm-commits]

markus added a comment.

In D56587#1354312 <https://reviews.llvm.org/D56587#1354312>, @aprantl wrote:

> >> ii) It is probably not safe to assume that the consumer/debugger would set the high bits to zero in zero extension in e.g. the case that the variable has been spilled to memory.
>
> Why? The consumer should have truncate the fragment to its DW_AT_size, right?


But wouldn't the DW_AT_size at this point be for the wider type? If it was the case that the consumer could automatically handle the zext then I don't see why it would not also be able to handle the sext by itself.
I think the following example illustrates where it goes wrong. Again contrived as we have to do some tricks to get the consumer to read the value from memory.

  typedef unsigned short T;
  T foo(T d0, T d1, T d2, T d3, T d4, T d5, T d6, T d7, T d8, T x) {
      unsigned int y = x;
      return y;
  }
  int main(int argc, char **argv) {
      return foo(0, 1, 2, 3, 4, 5, 6, 7, 8, -1);
  }

  clang dbg.c -O0 -g3 -S -emit-llvm
  sed -i 's/optnone//' dbg.ll
  opt -mem2reg -instcombine dbg.ll -S -o dbg.opt.ll
  llc -O3 dbg.opt.ll -o dbg.s

Now modify the assembly in the caller to make sure that there are non-zero bits on the stack next to the 'x' argument.
i.e. replace

  pushq   $65535                  # imm = 0xFFFF

with

  pushq   $-1                  # imm = 0xFFFF

and finally assemble and test

  gcc dbg.s -o dbg
  gdb ./dbg

  (gdb) b foo
  Breakpoint 1 at 0x4004c8: file dbg.c, line 4.
  (gdb) run
  Starting program: /repo/elavkje/llvm/my-dbg-test/dwarf-sext/dbg 
  
  Breakpoint 1, foo (d0=0, d1=1, d2=2, d3=3, d4=4, d5=5, d6=6, d7=7, d8=8, x=65535) at dbg.c:4
  4           return y;
  (gdb) whatis x
  type = T
  (gdb) whatis T
  type = unsigned short
  (gdb) p y
  $1 = 4294967295
  (gdb) whatis y
  type = unsigned int
  (gdb)

and it should be clear that zero extension did not happen. Unless my thinking is flawed of course, and that would not be the first time :)


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56587