The idea is to remove front-end analysis for the parameter's value modification and leave it to the value tracking system. Front-end in some cases mark a parameter as modified even the line of code that modifies the parameter gets optimized, that implies that this will cover more entry values even for unmodified parameters (GCC generates entry values in the situations like that, because it performs such analysis within its own value tracking system). In addition, extending the support for modified parameters will be easier with this approach.
Since the goal is to recognize if a parameter’s value has changed, the idea at very high level is: If we encounter a DBG_VALUE other than the entry value one describing the same variable (parameter), we can assume that the variable’s value has changed and we should not track its entry value any more. That would be ideal scenario, but due to various LLVM optimizations, a variable’s value could be just moved around from one register to another (and there will be additional DBG_VALUEs describing the same variable), so we have to recognize such situation (otherwise, we will lose a lot of entry values) and salvage the debug entry value.
The failure was:
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.