When you build a static library that includes DWARF information, you may encounter error messages in the binary package generated by Xcodebuild. Upon examining the DWARF information with dwarfdump, you will find that any entries containing keywords like dir are all absolute paths specific to the publisher's computer.
This is quite alarming, as it poses a risk of leaking private information. Additionally, when debugging an app, you can encounter consistent warning notes indicating that the referenced path addresses cannot be found. This is because the absolute path addresses generated during the 'xcodebuild' process reflect the paths from the computer used to build it. When distributing this to others, how can anyone access these paths?
Has the design of the secondary linking process for DWARF considered the issues related to binary distribution?
- Are there existing solutions to address and handle privacy concerns?
- Is there a solution to allow the distributed DWARF files to be correctly recognized during compilation and debugging of the app?
BTW: Incorrect paths can indeed affect LLDB's ability to load and debug the application effectively?
It’s not clear to me whether you’re trying to:
-
Keep things secret
-
Allow clients of your static library to debug
There’s a significant tension between these two; you can’t support debugging and keep everything secret.
Anyway, lemme start with the debugging situation. You are correct that:
-
The compiler encodes a bunch of full paths into DWARF debugging information.
-
If these paths don’t resolve, LLDB will have problems.
An easy way around this is to set up source path mappings. To learn more about this, consult the LLDB help:
(lldb) apropos target.source-map
However, this is not your only option. For example:
-
Various compilers have various options to cause them to embed relative paths.
-
Or you can build your shipping libraries on a build server that uses a standard non-private path.
There’s a whole world of info about this stuff out there on the ’net. A good search term is reproducible builds. In fact, one of my colleagues was has been discussing this with another developer recently in Reproducible Builds on iOS.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
