After #167359 / 95db31e7f69e7008f0c570ed30d54d1e418e10f2. A fix was attempted in #167423 but was not quite enough. From what I could understand, in v1 format you have to specify all the basic blocks. Where before !call_me implied they were all cold (I think, very shaky understanding here). For this test we want to see blocks like call_me/foo/call_me. So adding a line for block 1 fixes the tests. It could produce more blocks at some point but I think as long as foo is within two of them, it'll be fine.
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`.
When a thread reaches a breakpoint at the return address set by `ThreadPlanStepOut`, `ThreadPlanStepOut::ShouldStop()` calls `ThreadPlanShouldStopHere::InvokeShouldStopHereCallback()`, and if it returns `false`, `ThreadPlanShouldStopHere::QueueStepOutFromHerePlan()` is called to queue a new plan to skip the corresponding range. Once the new plan finishes, `ThreadPlanStepOut::ShouldStop()` should recheck the stop condition; however, there is no code path in the method that sets `done` to `true`. Before #126838, if `done` was `false`, the method checked if a suitable frame had been reached. After the patch, the check is only performed at a breakpoint; thus, the execution continues. This patch causes `ThreadPlanStepOut::ShouldStop()` to recheck the stop condition when `m_step_out_further_plan_sp` completes.
GCC 14 also made this an error by default, so we’re following suit. Fixes #74605
`INSERT BEFORE` keyword is not supported in current versions gold and mold linkers. Since we cannot confirm accurately what linker and version is available on the system and when it will be supported. We test it with a sample program using the script keywords.
This case is passing since https://github.com/llvm/llvm-project/pull/152020.
Failing on the macOS matrix bot for Clang-15 with the following error:
```
07:16:08 FAIL: LLDB (/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang-arm64) :: test_jump_offset_dwarf (TestThreadJump.ThreadJumpTestCase)
07:16:08 UNSUPPORTED: LLDB (/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/clang_1501_build/bin/clang-arm64) :: test_jump_offset_dwo (TestThreadJump.ThreadJumpTestCase) (test case does not fall in any category of interest for this run)
07:16:08 Restore dir to: /Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/lldb-build/tools/lldb/test
07:16:08 ======================================================================
07:16:08 FAIL: test_jump_offset_dsym (TestThreadJump.ThreadJumpTestCase)
07:16:08 Test Thread Jump by negative or positive offset
07:16:08 ----------------------------------------------------------------------
07:16:08 Traceback (most recent call last):
07:16:08 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1804, in test_method
07:16:08 return attrvalue(self)
07:16:08 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/functionalities/thread/jump/TestThreadJump.py", line 112, in test_jump_offset
07:16:08 self.expect(f"print {var_2}", substrs=[var_2_value])
07:16:08 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2512, in expect
07:16:08 self.fail(log_msg)
07:16:08 AssertionError: Ran command:
07:16:08 "print var_2"
07:16:08
07:16:08 Got output:
07:16:08 (int) 20
07:16:08
07:16:08 Expecting sub string: "40" (was not found)
```
Fixes #45326 When you thread jump by calling `j +2` or `thread jump --by +2` the offset is not recognised. This commit fixes that. --------- Signed-off-by: Ebuka Ezike <yerimyah1@gmail.com>
The architectures provided to skipIf / expectedFail are regular expressions (v. _match_decorator_property() in decorators.py so on Darwin systems "arm64" would match the skips for "arm" (32-bit Linux). Update these to "arm$" to prevent this, and also update three tests (TestBuiltinFormats.py, TestCrossDSOTailCalls.py, TestCrossObjectTailCalls.py) that were skipped for arm64 via this behavior, and need to be skipped or they will fail. This was moviated by the new TestDynamicValue.py test which has an expected-fail for arm, but the test was passing on arm64 Darwin resulting in failure for the CIs.