commit 64df8f83fe293b6c08477975cbb4451c76b51c54
author Igor Kudrin <ikudrin@accesssoftek.com> Tue Oct 21 20:01:08 2025 -0700
committer GitHub <noreply@github.com> Tue Oct 21 20:01:08 2025 -0700
tree f95eace9648fd500401d78589d5d115f57a33229
parent 1906c3e1e30759d2eb85b2833e8c5ff64128bfba

[lldb][test] Fix TestEmptyFuncThreadStepOut.py (#161788)

The test did not work as intended when the empty function `done()`
contained prologue/epilogue code, because a breakpoint was set before
the last instruction of the function, which caused the test to pass even
with the fix from #126838 having been reverted.

The test is intended to check a case when a breakpoint is set on a
return instruction, which is the very last instruction of a function.
When stepping out from this breakpoint, there is interaction between
`ThreadPlanStepOut` and `ThreadPlanStepOverBreakpoint` that could lead
to missing the stop location in the outer frame; the detailed
explanation can be found in #126838.

On `Linux/AArch64`, the source is compiled into:
```
> objdump -d main.o
0000000000000000 <done>:
   0:   d65f03c0        ret
```
So, when the command `bt set -n done` from the original test sets a
breakpoint to the first instruction of `done()`, this instruction
luckily also happens to be the last one.

On `Linux/x86_64`, it compiles into:
```
> objdump -d main.o
0000000000000000 <done>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   5d                      pop    %rbp
   5:   c3                      ret
```
In this case, setting a breakpoint by function name means setting it
several instructions before `ret`, which does not provoke the
interaction between `ThreadPlanStepOut` and
`ThreadPlanStepOverBreakpoint`.