[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