Are there any lldb settings that can allow for faster debug startup of the application? Specifically a native macOS app. The app that I work on has a couple of multi-gig debug dylibs that in total takes about 40s for lldb to process each time that an incremental code change happens to either of the libraries.
I was able to create a sample project that creates a libD.dylib which makes a barebones mac app in Xcode take about 45s for lldb to do symbol parsing + image/module loading. The app is simple, but it contains a large libD.dylib (3.86GB DWARF + debug). libD.dylib is embedded in the app, but the library is never even invoked.
From enabling logging in my lldbinit with:
log enable lldb all
log disable lldb demangle
I can see that lldb is spending most of it’s time loading the libD.dylib image. Specifically, lldb is sitting at this part for 25s as the main stopping point:
0x1237681c8 Module::Module((arm64) '/Users/user/Library/Developer/Xcode/DerivedData/DylibLoader-eqtwfxxjbyvvgtfgbpuwplodrvgf/Build/Products/Debug/DylibLoader.app/Contents/Frameworks/libD.dylib')
0x123767ba0 ObjectFile::ObjectFile() module = 0x1237681c8 (/Users/user/Library/Developer/Xcode/DerivedData/DylibLoader-eqtwfxxjbyvvgtfgbpuwplodrvgf/Build/Products/Debug/DylibLoader.app/Contents/Frameworks/libD.dylib), file = /Users/user/Library/Developer/Xcode/DerivedData/DylibLoader-eqtwfxxjbyvvgtfgbpuwplodrvgf/Build/Products/Debug/DylibLoader.app/Contents/Frameworks/libD.dylib, file_offset = 0x00000000, size = 3859201184
Is there anything that can be done to tell lldb to simply not do whatever processing it’s doing in that image loading step? To especially drive home that lldb is doing more than necessary, the library is not actually invoked by the application ever, it’s only embedded in the app (as a test). Talking to coworkers on other platforms for our product, WinDbg is able to connect to the app immediately and only do any symbol processing later on when a breakpoint is hit. This makes incremental changes of the app very quick because the app can startup immediately and is only slow if you need to set a breakpoint (a reasonable tradeoff).
I’ve tried Xcode 15 which contains llvm 16, which adds the new settings set symbols.load-on-demand true, but only stops individual .o modules from getting loaded from the offending dylib, but lldb is still doing something with the overall dylib module on startup that takes the above time. So this does not seem to help.
Also to be clear, if there was no code change, as expected, the debug app starts up quickly because the large dylib is cached in Xcode’s lldb instance. This problem is specifically for developers making small incremental changes.
We have an initiative to try and split these binaries up for some other reasons (this is one of them), but that’ll be a long journey. Any help or suggestions for a way to tell lldb to postpone whatever are greatly appreciated!
More details on the above:
- ~1GB mac app bundle of Swift/Obj-c (size is DWARF with debug symbols)
- ~2GB dylib of C++ (size is DWARF with debug symbols)
- The 40s above is on an M2 Max, Intel macs take usually about 1min.