Finding the executables that a binary will load on run before you actually run is always best effort. We don't require the ObjectFile class to fully emulate the platform loader. So from the standpoint of writing tests, if the test relies on getting symbols from a loaded library it should always run to the point where the library actually got loaded.
That being said, ObjectFileMachO does detect @executablePath and has code to try to do the right thing. So that's apparently broken. I'll take a look and see what broke. We should also write a test that platforms can sign up for their level of loader emulation so we can make sure the stated level of support doesn't regress. Jim > On Mar 15, 2017, at 5:46 AM, Pavel Labath <lab...@google.com> wrote: > > Hi Jim, > > I am not sure if behavior like this should be considered a bug, but I > wanted to make sure you don't miss this. > > cheers, > pl > > > On 15 March 2017 at 12:32, Pavel Labath via lldb-commits > <lldb-commits@lists.llvm.org> wrote: >> Author: labath >> Date: Wed Mar 15 07:32:18 2017 >> New Revision: 297830 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=297830&view=rev >> Log: >> Fix TestMoveNearest breakage on darwin >> >> It seems that on darwin we are not able to resolve breakpoints in the >> test shared library until the process has started. That seems >> unfortunate, but it is not the purpose of this test, so work around that >> by starting the process before doing the rest of our checks. >> >> Modified: >> >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/TestMoveNearest.py >> >> Modified: >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/TestMoveNearest.py >> URL: >> http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/TestMoveNearest.py?rev=297830&r1=297829&r2=297830&view=diff >> ============================================================================== >> --- >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/TestMoveNearest.py >> (original) >> +++ >> lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/move_nearest/TestMoveNearest.py >> Wed Mar 15 07:32:18 2017 >> @@ -27,6 +27,10 @@ class TestMoveNearest(TestBase): >> target = self.dbg.CreateTarget("a.out") >> self.assertTrue(target, VALID_TARGET) >> >> + lldbutil.run_break_set_by_symbol(self, 'main', sym_exact=True) >> + process = target.LaunchSimple(None, None, >> self.get_process_working_directory()) >> + self.assertEquals(process.GetState(), lldb.eStateStopped) >> + >> # Regardless of the -m value the breakpoint should have exactly one >> # location on the foo functions >> self.runCmd("settings set target.move-to-nearest-code true") >> >> >> _______________________________________________ >> lldb-commits mailing list >> lldb-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
