Symbols on macOS documents that an UUID property list can be embedded in the dSYM bundle. Among other things this property list allows to specify DBGSourcePath, DBGBuildSourcePath and DBGSourcePathRemapping.
My question is whether it’s possible to specify a path relative to the dSYM bundle for the purpose of shipping source code files inside the bundle.
One benefit to having our DWARF debug info in a dSYM bundle (a directory) instead of just a plain file is that we have the option of including additional data in there as well. You could envision putting a copy of the source code in the dSYM bundle too, maybe xar’ed and compressed, and having the debugger expand it as-needed when debugging.
My superficial code review shows that relative paths are not rejected outright, but are resolved with respect to the current working directory of whatever process parses the plist. However, it’s not clear whether the working directory is adjusted to the bundle.
Embedded the source in the .dSYM bundle never progressed beyond “this might be useful” stage, and there’s no support, currently, for specifying a remap path relative to the bundle directory. It doesn’t help any of the workflows at Apple so I haven’t explored the idea beyond “Hey this could be useful”, unfortunately; for instance, I’d never thought of the path remapping aspect of it. We’d probably need to add a new key-value to the plist in the .dSYM bundle that specifies the compile-time directory string that should be substituted for the dSYM bundle filepath (the code that interprets these has the Module so it’s easy to get the SymbolFile FileSpec or ObjectFile FileSpec if the dSYM is being used as the ObjectFile), and we’d need to define a canonical place in the dSYM bundle for this like .dSYM/Contents/Resources/Source or something like that.
Would it be too unsafe to attempt to resolve relative paths in the plist with respect to the directory that contains the plist file itself, i.e. dSYM’s Contents/Resources. I’d think that with this change in behavior one could reuse existing DBGBuildSourcePath and DBGSourcePath without advancing DBGVersion.
I always worry about adding a new interpretation for something that is PROBABLY not used by anything currently. e.g. there could be someone who has a workflow of “run lldb in a directory above the sources” and had relative path remappings that would correctly find the sources. It seems unlikely but that’s my only concern with this proposal. Maybe other people will weigh in.
Current implementation seems to verify whether path exists before considering it. So for that particular use-case the issue can be avoided by attempting the relative-to-plist path last.