summaryrefslogtreecommitdiff
path: root/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
diff options
context:
space:
mode:
Diffstat (limited to 'lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py')
-rw-r--r--lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py29
1 files changed, 29 insertions, 0 deletions
diff --git a/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py b/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
new file mode 100644
index 000000000000..f0a7aef182a6
--- /dev/null
+++ b/lldb/test/API/lang/cpp/function-call-from-object-file/TestFunctionCallFromObjectFile.py
@@ -0,0 +1,29 @@
+"""
+Tests that we can call functions that have definitions in multiple
+CUs in the debug-info (which is the case for functions defined in headers).
+The linker will most likely de-duplicate the functiond definitions when linking
+the final executable. On Darwin, this will create a debug-map that LLDB will use
+to fix up object file addresses to addresses in the linked executable. However,
+if we parsed the DIE from the object file whose functiond definition got stripped
+by the linker, LLDB needs to ensure it can still resolve the function symbol it
+got for it.
+"""
+
+import lldb
+from lldbsuite.test.decorators import *
+from lldbsuite.test.lldbtest import *
+from lldbsuite.test import lldbutil
+
+
+class TestFunctionCallFromObjectFile(TestBase):
+ def test_lib1(self):
+ self.build()
+ lldbutil.run_to_name_breakpoint(self, "lib1_func")
+
+ self.expect_expr("Foo{}.foo()", result_type="int", result_value="15")
+
+ def test_lib2(self):
+ self.build()
+ lldbutil.run_to_name_breakpoint(self, "lib2_func")
+
+ self.expect_expr("Foo{}.foo()", result_type="int", result_value="15")