[Lldb-commits] [PATCH] D68209: [LiveDebugValues] Introduce entry values of unmodified params

Vedant Kumar via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Wed Dec 4 14:29:07 PST 2019


vsk added inline comments.


================
Comment at: lldb/packages/Python/lldbsuite/test/functionalities/param_entry_vals/basic_entry_values_x86_64/main.cpp:159
   // FUNC11-BT: func11_tailcalled{{.*}}
   // FUNC11-BT-NEXT: func12{{.*}} [artificial]
   use(x);
----------------
djtodoro wrote:
> vsk wrote:
> > The failure was:
> > ```
> > main.cpp:159:21: error: FUNC11-BT-NEXT: expected string not found in input
> >  // FUNC11-BT-NEXT: func12{{.*}} [artificial]
> >                     ^
> > <stdin>:3:2: note: scanning from here
> >  frame #1: 0x00000001079eae69 a.out`func12(sink=0x00007ffee8215cb4, x=123) at main.cpp:179:3 [opt]
> > ```
> > 
> > The added `DESTROY_RBX` asm might confuse TailRecursionElimination into believing that the callee accesses the caller's stack. Could you double-check that a tail call is actually emitted in `func12` (something like `jmp *%rax`)? If it //is//, this is a pre-existing lldb bug, so the func12 test should be disabled.
> @vsk Thanks for the comment!
> 
> The problem here is the fresh change in the code production by using the `-O1` level of optimization. More precisely, at very high level, after the D65410 we do not have a tail call where we expected.
> I am proposing using the `-O2` level of the optimizations, since we are testing printing of the entry values in the test case, rather than tail call frames with particular level of optimization.
> WDYT? 
Sounds good to me, thanks for chasing that down!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68209





More information about the lldb-commits mailing list