<div dir="ltr">Thank you for the very detailed explanation Greg! Good to know about why DBGSpotlightPaths was not working and that DBGSearchPaths is a possible option. I do expect this directory will get quite large so it looks like DBGFileMappedPaths is the better alternative.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 17, 2021 at 6:53 PM Greg Clayton <<a href="mailto:clayborg@gmail.com">clayborg@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">DBGSpotlightPaths is to limit spotlight searches to _only_ those directories, but they must be valid locations that spotlight would normally index. If you want to see if spotlight indexes a directory that contains a dSYM file, then you can us "mdls":<div><br></div><div>$ mdls a.out.dSYM<br>_kMDItemDisplayNameWithExtensions      = "a.out.dSYM"<br>com_apple_xcode_dsym_paths             = (<br>    "Contents/Resources/DWARF/a.out"<br>)<br>com_apple_xcode_dsym_uuids             = (<br>    "4B8A7479-4DF6-3828-AB99-3EF71E79B00E"<br>)<br><br><div><br></div><div>if you see "com_apple_xcode_dsym_paths" and "com_apple_xcode_dsym_uuids", then spotlight already indexes this directory and nothing should need to be done. This won't work for locations that spotlight normally doesn't index like "/tmp/*", "~/Library/Caches/*" and many more locations. This will just let you know if spotlight is indexing files already.</div><div><br></div><div>If you have a directory that contains dSYM files that you want to search, you have a few options:</div><div>1 - specify a directory that will be used for the current LLDB session only</div><div>2 - add dsym files manually as you need them</div><div>3 - specify a directory that will always be searched for all debug sessions</div><div><span style="white-space:pre-wrap">  </span></div><div><br></div><div>For solution #1 you can do this in LLDB with a setting:</div><div><br></div><div>(lldb) settings set target.debug-file-search-paths /symbols/dir/number1 [/symbols/dir/number2 ...]</div><div>(lldb) target create ....</div><div><br></div><div>Any dSYM files that aren't found by spotlight, will fall back and look for matching dsym files in the directories you specify for the current LLDB session only.</div><div><br></div><div>For solution #2, you can add dSYM files manually:</div><div><br></div><div>(lldb) target create a.out</div><div>(lldb) target symbols add /path/to/libfoo.dSYM</div><div><br></div><div>LLDB will find the executable that matches /path/to/libfoo.dSYM and add it</div><div><br></div><div>For solution #3, you can modify the DebugSymbols.framework global defaults which will help LLDB and any other Xcode tools (sample, Instruments, Xcode, etc) to find your symbols:</div><div><br></div><div><div>$ defaults write com.apple.DebugSymbols DBGSearchPaths -string /single/path/to/search</div><div>$ defaults write com.apple.DebugSymbols DBGSearchPaths -array /path/to/search1 /path/to/search2</div><div><br></div><div>The main issue with this settings, is each time you have a program that loads DebugSymbols.framework (like LLDB), it will need to scan this entire directory and find all matching dSYM files. If you end up placing a lot of files in this directory, then it can become a performance cost. So this method is not preferred due to its possible costs that depends on how many dSYM files are in these directories.</div><div><br></div><div><br></div><div>A better solution that works well for solution #3 but has no cost associated with it is to store you dSYM files in a directory that isn't indexed by spotlight, then have a script that ends up chopping up your UUID into 4 byte hex values as specified in <a href="https://lldb.llvm.org/use/symbols.html#id3" target="_blank">File Mapped UUID Directories</a> page. This allows direct access for looking up symbol files when needed and doesn't cost you much besides a few stat() calls when you are looking for specific symbols.</div><div><br></div><div>More comments inlined below!</div><div><br></div><br><br></div><div><br><blockquote type="cite"><div>On Feb 11, 2021, at 8:29 AM, Ivan Hernandez via lldb-dev <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr"><div>Hello,</div><div><br></div><div>I am in need of configuring dSYM lookups on macOS for a directory under ~/Library/Caches which is not indexed by Spotlight and does not seem to be picked up when adding my directory to DBGSpotlightPaths. </div></div></div></blockquote><div><br></div><div>Spotlight purposely doesn't index in ~/Library/Caches at all and DBGSpotlightPaths setting for DebubSymbols.framework is used to only limit spotlight's search to existing directories. The DBGSpotlightPaths setting is typically used when you might have multiple external drives and you want to limit spotlight searches to only a few root drives that contain symbols. It won't cause a location that isn't indexed by Spotlight to suddenly become indexed.</div><br><blockquote type="cite"><div><div dir="ltr"><div>The <a href="https://lldb.llvm.org/use/symbols.html" target="_blank">Symbols on macOS</a> page includes "Explicit search paths" as a method of dSYM lookups but mentions no way of configuring it. I happened to come across this very old <a href="https://opensource.apple.com/source/gdb/gdb-696/doc/ReleaseNotes.xml" target="_blank">GDB release notes</a> page which mentions that DBGSearchPaths can be used to configure explicit search paths. </div></div></div></blockquote><div><br></div><div>Yes this is correct as I detailed above, but it comes with unacceptable costs according to most people as each process has to scan these directories recursively, so you want to make sure to specify a directory with only a few files if you do end up using this method. If you specify an entire hard drive, each time you start a process that uses DebugSymbols.framework, it will recursively search the entire drive and all subdirectories for dSYM files which can obviously slow things down!</div><div><br></div><br><blockquote type="cite"><div><div dir="ltr"><div>I can use DBGFileMappedPaths or DBGShellCommands but DBGSearchPaths seems to be working fine and looks like a much simpler approach if it is intended to be supported in the long term.</div></div></div></blockquote><div><br></div>It has been support for over 10 years, so yes, this is supported and will continue to be, as long as you know the costs involved and are ok with that, you can use this method.</div><div><br></div><div>Greg Clayton<br><blockquote type="cite"><div><div dir="ltr"><div><br></div><div>Thanks,</div><div>Ivan</div></div>
_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a><br><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev</a><br></div></blockquote></div><br></div></div></blockquote></div>