[Lldb-commits] [lldb] [lldb] Put the thread until backstop in the caller of the concrete frame (PR #226075)

[via lldb-commits]

jimingham wrote:

> This commit fixes a bug with thread-until, making LLDB's behavior similar to GDB's in code with inlined functions.
> 
> For example, consider this backtrace:
> 
> ```
>       frame #0: 0x00000001000003c0 deep`sink(x=81) at deep.c:4:6 [opt]
>       frame #1: 0x0000000100000418 deep`level3(a=48) at deep.c:11:3 [opt] [inlined]
>       frame #2: 0x0000000100000404 deep`level2(b=37) at deep.c:20:3 [opt] [inlined]
>       frame #3: 0x00000001000003f0 deep`level1(c=42) at deep.c:28:3 [opt] [inlined]
>       frame #4: 0x00000001000003dc deep`main at deep.c:33:3 [opt]
> ```
> 
> This patch changes behavior as follows:
> 
> ```
> command                             gdb           lldb before    lldb after
> until -f 1 <later line in frame 2>  that line     process exits  that line
> until -f 2 <later line in frame 1>  that line     process exits  that line
> until -f 1 <line that already ran>  main returns  process exits  main returns
> ```
> 
> TestInlineFrameUntil covers these cases.
> 
> `thread until -f N` put its return breakpoint at the PC of frame N+1. When frame N+1 is an inline frame, that PC is the start of the inlined code of frame N, which already ran; in other words, this breakpoint will never be hit and the process runs to exit.

That behavior is wrong, thread until is never supposed to run away.  Presumably that was just a bug in trapping "exit from an inlined frame."  Haven't looked at the implementation yet.

> 
> Also, an until breakpoint counted as reached only in the inline scope of frame N, so a target in another inline scope of the same concrete frame was ignored.
> 

I'm not sure what you mean here.  If I'm in a recursive call with no inlining, so frames 0, 1 and 2 are all concrete frames running the function `foo`.  If I say:

(lldb) thread until -f 2 100

 it would not be correct to stop when frame 1 executes line 100.  You should only stop either when the frame with the stackID that was at frame 2 when the `until` was issued executes line 100, or when that frame exits.

It seems like you are saying we shouldn't have the same behavior if frames 0-2 happen to be inlined?  As much as possible, lldb treats inlined and concrete frames identically.

> The return breakpoint now goes in the first frame after N that is in a different concrete frame. An until breakpoint now counts as reached when frame zero has the CFA of frame N.

Again, that seems like you are now giving `thread until` different behaviors depending on whether it was issued in an inlined and a concrete frame, but unless we're actually forced to because we can't come up with a working implementation, we should keep these behaviors the same.

https://github.com/llvm/llvm-project/pull/226075