This certainly should be cleared up and centralized. I'm not quite as sure it should be in Platform however. For instance, macOS has the DebugSymbols framework that allows users to specify a local lookup tool to find symbol files given a UUID. That runs only on MacOS and requires MacOS specific headers to build. So that makes it a Host facility. But there's no reason you couldn't use this mechanism for finding Linux symbol files when cross debugging. So that makes it sound more like this Platform symbol finding facility you're envisioning. I'm still a little unclear about the distinction between Host, Platform when the platform isn't the same as the Host, and Platform when it happens to be the same as the Host.
But maybe this is clear and I just haven't studied the more recent manifestations of the code recently. Jim > On Dec 1, 2017, at 3:29 AM, Pavel Labath <lab...@google.com> wrote: > > On 30 November 2017 at 19:08, Jim Ingham <jing...@apple.com> wrote: >> We had a similar problem with the tests on macOS. lldb has a facility that >> will do automatic lookup of UUID -> dSYM (macOS's separate debug info >> format) and if you are internal to Apple this will find all the system >> library debug info. That will cause a handful of tests to fail, mostly >> because the presence of debug information changes stepping behavior. >> doTest.py has a method: "checkDsymForUUIDIsNotOn" to ensure that this >> facility is turned off and if it is not will warn you and abort the test run. >> >> You are going to have to do something of that sort even once you get reading >> these libraries in to work, so I agree a setting seems like a good idea. >> There is a setting for debug file search paths: >> target.debug-file-search-paths but I'd rather not add a special cookie to >> that since you can imagine wanting to point to a directory with your debug >> info and ALSO not read in the system debug info. So it would be better IMO >> to add a parallel debug-file-avoid-directory setting. >> > > I think the relevant logic here is in Host/common/Symbols.cpp, and > there it's just hard-coded to /usr/lib/debug, and does not respect any > settings. What I'd like to see one day is to move this piece of code > into the Platform class and add some "sysroot"-like setting that > controls it. This has a couple of benefits: > - it can be used for remote debugging (if you can a copy/nfs mount of > the remote system, you can just set sysroot to that) > - we can set this to /nonexistent for all tests, as you never want to > depend on that logic finding some debug info > - *except*, when you actually want to test this logic, and in that > case you can set the sysroot so some path that you have control of > - (I think) Stephane would be able to test D40539 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
