When debugging a remote Darwin device (iOS, macOS, etc), lldb needs to
find a local copy of all the system libraries (the system's shared
cache) so we don't need to read them over gdb-remote serial protocol at
the start of every debug session.
Xcode etc normally creates these expanded shared caches in
~/Library/Developer/Xcode/<OS> DeviceSupport/<OS VER> (<OS
BUILD>)/Symbols
So when lldb sees a file like /usr/lib/libSystem.B.dylib, it may find a
copy at in
~/L/D/Xcode/iOS DeviceSupport/26.2
(23B87)/Symbols/usr/lib/libSystem.B.dylib
There may be multiple expanded shared caches in these DeviceSupport
directories, so we try to parse the "os version" and "os build" out of
the filepath name, and look in a directory that matches the target
device's OS Version as an optimization, to avoid opening the given file
in other DeviceSupport directories.
There is a new layout where the cpu arch exists as a subdirectory under
the "<OS VER> (<OS BUILD>)" directory. e.g.
~/L/D/Xcode/iOS DeviceSupport/26.2 (23B87)/arm64e/Symbols/...
and it is possible that we could have multiple arch names for a given
build -- for instance, an Apple Watch that can have either arm64e or
arm64_32 shared caches.
The existing code also had a very simplistic way of parsing "<OS VER>
(<OS BUILD>)" from the directory name that hasn't been kept up to date
with how the directory names have changed over the years. We have some
like "Watch4,2 10.0 (21R329)" or "10.0 (21R329) universal" which may not
parse with the older parser.
This PR looks for target arch subdirs under the given directories,
passes the os version/build version string separately because it may not
be the final component in the directory name any more, and updates the
directory parser that finds the version and build numbers.
rdar://171821410
5b00cdf8e1