If I set a custom working directory in the Xcode scheme, it seems to have no effect whatsoever on source mapping to debug symbols.
First I will give some background for a little context, then I will describe the problem in more detail.
We build thousands of shared libraries in centralized build locations, and the debug info points to the build area where the debug symbols were created.
For example, if a file /build/main/foo/bar.cpp was built in the build area, it's AT_comp_dir would look like this:
AT_name("bar.cpp")
AT_comp_dir("/build/main/foo")
(Suffice it to say that the "main" directory is the current working directory where the debugger would get launched.)
If our developers sync a sandbox and try to hit breakpoints in their sandbox sources, the breakpoints either don't get hit or get hit in the build area sources. This is expected, since the symbols point to the build area sources, because that is where the symbols were created.
This causes great pain during development, because developers have to regenerate the debug symbols in order to hit breakpoints in their sandbox sources.
Therefore, in order to make sure the debug symbols always get resolved in developer sandbox sources (instead of resolving to build area source locations), we are passing the following flags to the compiler:
-Xclang -fdebug-compilation-dir -Xclang <relative_dir_after_main>
So in the /build/main/foo/bar.cpp example, AT_comp_dir now looks like this:
AT_name("bar.cpp")
AT_comp_dir("foo")
If the developer cd's to the /build/main directory and debugs with LLDB from the command-line, sources are found and breakpoints get hit. This is expected.
However, this does not work in an Xcode project.
Setting a breakpoint at bar.cpp in the project with the Xcode UI causes the breakpoint to never get hit. Setting that breakpoint through Xcode's LLDB command-line interface causes the breakpoint to get hit, but only assembly is shown, proving that the source could not be mapped.
I tried setting the custom working directory option to /build/main in the Xcode scheme but that seemed to have no effect whatsoever.
I proved this by asking LLDB its current working directory after my debug session starts:
(lldb) script import os; print os.getcwd() /
As you can see, the current working directory used is /, which is the standard default working directory for launched apps, but isn't what we want. Since I cannot use Xcode's custom working directory option to set the working directory to /build/main, the relative path foo/bar.cpp in AT_comp_dir is never resolved.
This is VERY frustrating as it prevents us from using relative compiation dirs in the debug info. This would work perfectly if the custom working directory Xcode option was passed down to LLDB.
Can anyone tell me how to get LLDB to resolve the relative AT_comp_dir paths from within Xcode?
The biggest hard requirement here is that it must be something that can be conifgured at the project-level or something that can be default initialized from LLDB - the solution cannot require user action on a per-session basis (that won't scale for our develoeprs).
Note: Using the target.source-map setting in LLDB is not an option, even if used in .lldbinit, because the "from" path is relative and the "to" absolute path is subject to change freqently (with each new sandbox). Also, I've never actually ben able to get target.source-map to work.
Any help would be appreciated!!!