Change how LocateDSYMInVincinityOfExecutable strips off path

components to not depend on "." characters in the fileanme
(e.g. "Foundation.framework") but instead to just use path
separators.  The names of the files themselves may have dots
in them ("com.apple.sbd") which would break the old scheme.

Also add a test case for this (macosx/find-dsym/bundle-with-dot-in-filename)
as well as a test case for r304520 (macosx/find-dsym/deep-bundle)
which needed a similar setup to test correctly on a single machine.
(both of these are really testing remote debug session situations
where the binary can't be found on the system where lldb is running,
complicating the test case a bit.)

<rdar://problem/31825940> 

llvm-svn: 305441

1 files changed, 22 insertions, 0 deletions

diff --git a/lldb/packages/Python/lldbsuite/test/macosx/find-dsym/deep-bundle/main.c b/lldb/packages/Python/lldbsuite/test/macosx/find-dsym/deep-bundle/main.c
new file mode 100644
index 00000000000..19715216d6c
--- /dev/null
+++ b/lldb/packages/Python/lldbsuite/test/macosx/find-dsym/deep-bundle/main.c
@@ -0,0 +1,22 @@
+#include <MyFramework/MyFramework.h>
+#include <unistd.h>
+#include <stdlib.h>
+
+int setup_is_complete = 0;
+
+int main()
+{
+    system ("/bin/rm -rf MyFramework MyFramework.framework MyFramework.framework.dSYM");
+
+    setup_is_complete = 1;
+
+    // At this point we want lldb to attach to the process.  If lldb attaches
+    // before we've removed the framework we're running against, it will be
+    // easy for lldb to find the binary & dSYM without using target.exec-search-paths,
+    // which is the point of this test.
+
+    for (int loop_limiter = 0; loop_limiter < 100; loop_limiter++)
+        sleep (1);
+
+     return foo();
+}