Control the "step out through thunk" logic explicitly when pushing thread plans (llvm#129301)

Jonas recently added a trampoline handling strategy for simple language
thunks that does: "step through language thunks stepping in one level
deep and stopping if you hit user code". That was actually pulled over
from the swift implementation. However, this strategy and the strategy
we have to "step out past language thunks" when stepping out come into
conflict if the thunk you are stepping through calls some other function
before dispatching to the intended method. When you step out of the
called function back into the thunk, should you keep stepping out past
the thunk or not?

In most cases, you want to step out past the thunk, but in this
particular case you don't.

This patch adds a way to inform the thread plan (or really it's
ShouldStopHere behavior) of which behavior it should have, and passes
the don't step through thunks to the step through plan it uses to step
through thunks.

I didn't add a test for this because I couldn't find a C++ thunk that
calls another function before getting to the target function. I asked
the clang folks here if they could think of a case where clang would do
this, and they couldn't. If anyone can think of such a construct, it
will be easy to write the step through test for it...

This does happen in swift, however, so when I cherry-pick this to the
swift fork I'll test it there.

(cherry picked from commit ddbce2f)
(cherry picked from commit 169fb46)

Author: jimingham

lldb/source/Plugins/LanguageRuntime/Swift/SwiftLanguageRuntimeNames.cpp

@@ -525,9 +525,12 @@ static lldb::ThreadPlanSP GetStepThroughTrampolinePlan(Thread &thread,
                   GetThunkKindName(thunk_kind));
     AddressRange sym_addr_range(sc.symbol->GetAddress(),
                                 sc.symbol->GetByteSize());
-    return std::make_shared<ThreadPlanStepInRange>(thread, sym_addr_range, sc,
+    ThreadPlanSP new_plan_sp = std::make_shared<ThreadPlanStepInRange>(thread, sym_addr_range, sc,
                                                    nullptr, eOnlyDuringStepping,
                                                    eLazyBoolNo, eLazyBoolNo);
+    static_cast<ThreadPlanStepInRange *>(new_plan_sp.get())
+        ->GetFlags().Clear(ThreadPlanShouldStopHere::eStepOutPastThunks);
+    return new_plan_sp;     
   }
   }
 

lldb/test/API/lang/swift/step_through_allocating_init/Makefile

@@ -0,0 +1,6 @@
+SWIFT_SOURCES := main.swift
+include Makefile.rules
+
+cleanup:
+	rm -f Makefile *.d
+

lldb/test/API/lang/swift/step_through_allocating_init/TestStepThroughAllocatingInit.py

@@ -0,0 +1,74 @@
+import lldb
+from lldbsuite.test.decorators import *
+import lldbsuite.test.lldbtest as lldbtest
+import lldbsuite.test.lldbutil as lldbutil
+import os
+import platform
+
+class TestStepThroughAllocatingInit(lldbtest.TestBase):
+    mydir = lldbtest.TestBase.compute_mydir(__file__)
+
+    @swiftTest
+    def test_swift_stepping_api(self):
+        """Test that step in using the Python API steps through thunk."""
+        self.build()
+        self.do_test(True)
+
+    @swiftTest
+    def test_swift_stepping_cli(self):
+        """Same test with the cli - it goes a slightly different path than
+           the API."""
+        self.build()
+        self.do_test(False)
+
+    def setUp(self):
+        lldbtest.TestBase.setUp(self)
+        self.main_source = "main.swift"
+        self.main_source_spec = lldb.SBFileSpec(self.main_source)
+        # If you are running against a debug swift you are going to
+        # end up stepping into the stdlib and that will make stepping
+        # tests impossible to write.  So avoid that.
+
+        if platform.system() == 'Darwin':
+            lib_name = "libswiftCore.dylib"
+        else:
+            lib_name = "libswiftCore.so"
+
+        self.dbg.HandleCommand(
+            "settings set "
+            "target.process.thread.step-avoid-libraries {}".format(lib_name))
+
+    def do_test(self, use_api):
+        """Tests that we can step reliably in swift code."""
+        exe_name = "a.out"
+        exe = self.getBuildArtifact(exe_name)
+
+        target, process, thread, breakpoint = lldbutil.run_to_source_breakpoint(self,
+        'Break here to step into init', self.main_source_spec)
+
+        # Step into the function.
+        if use_api:
+            thread.StepInto()
+        else:
+            self.runCmd("thread step-in")
+        frame_0 = thread.frames[0]
+        self.assertIn('Foo.init()', frame_0.GetFunctionName())
+
+        # Check that our parent frame is indeed allocating_init (otherwise we aren't
+        # testing what we think we're testing...
+        frame_1 = thread.frames[1]
+        self.assertIn("allocating_init", frame_1.GetFunctionName())
+
+        # Step one line so some_string is initialized, make sure we can
+        # get its value:
+        thread.StepOver()
+        frame_0 = thread.frames[0]
+        self.assertIn('Foo.init()', frame_0.GetFunctionName())
+        var = frame_0.FindVariable("some_string")
+        self.assertTrue(var.GetError().Success())
+        self.assertEqual(var.GetSummary(), '"foo"')
+        
+        # Now make sure that stepping out steps past the thunk:
+        thread.StepOut()
+        frame_0 = thread.frames[0]
+        self.assertIn("doSomething", frame_0.GetFunctionName())

lldb/test/API/lang/swift/step_through_allocating_init/main.swift

@@ -0,0 +1,18 @@
+class Foo {
+    init() {
+      let some_string = "foo"
+      print(some_string)
+    }
+}
+
+func bar(_ _: Foo) {
+    print("bar")
+}
+
+func doSomething()
+{
+  let f = Foo() // Break here to step into init
+  bar(f)
+}
+
+doSomething()