[PATCH] D93497: Salvage debug info for function arguments in coro-split funclets.

Adrian Prantl via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 21 15:48:22 PST 2021


aprantl added a comment.

In D93497#2495103 <https://reviews.llvm.org/D93497#2495103>, @dongAxis1944 wrote:

> I do not see any other problems, but if the code use c++ program, it will cause lldb read invalid address like I write before:
>
>   Process 106638 stopped
>   * thread #1, name = 'a.out', stop reason = breakpoint 1.2
>       frame #0: 0x0000000000401bd0 a.out`foo(t=0x0000000000000000) at coro-debug-1.cpp:39:26
>      36     //   (int) i = 1
>      37
>      38     co_await suspend_always();
>   -> 39     printf("%d, %d, %d\n", i, j, t.i); // 2, 1
>                                    ^
>      40     // Breakpoint 2:
>      41     //   (lldb) frame variable i
>      42     //   (int) i = <variable not available>
>   (lldb) p t
>   error: Couldn't apply expression side effects : Couldn't dematerialize a result variable: couldn't read its memory: 0     ---->
>
>
>
> In D93497#2494295 <https://reviews.llvm.org/D93497#2494295>, @aprantl wrote:
>
>> It sounds like the bug @dongAxis1944 has found is unrelated to this patch. Should we move forward with this one, or are there any other problems you see?

I'm terribly sorry for being so slow to respond. I can't reproduce this particular issue:

     30  	coro foo(struct test & t) {
     31  	  int i = 0;
     32  	  int j = 0;
     33  	  i = t.i + t.j + t.k;
     34  	  printf("%d\n", i);
     35  	
     36  	  co_await suspend_always();
  -> 37  	  printf("%d, %d, %d\n", i, j, t.i); // --> A
      	                         ^
     38  	
     39  	  co_await suspend_always();
     40  	  ++i;
  Target 0: (e2.out) stopped.
  (lldb) v
  v
  (int) j = 0
  (int) i = 494
  (lldb) p t
  p t
  (test) $0 = (i = 238, j = 255, k = 1)
  (lldb) 

When you get the could not materialize error, is this for one of the variables that are duplicated by the frontend? If yes, then I wouldn't be too concerned about it. The frontend variable duplication is something we definitely have to fix, too, bu t I think it's orthogonal to this patch.


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

https://reviews.llvm.org/D93497



More information about the llvm-commits mailing list