This solves the problem of lldb not recognizing android vendor's ndks that can live along side the system ndks. More about this feature here: https://source.android.com/devices/architecture/vndk.
# A quick description of the problem
An android app can have vendor ndk's that are modified versions of the system ndk's (e.g.: `/system/lib/vndk-sp/libcutils.so` and `/system/lib/libcutils.so`). It's possible to configure how your app depends on one or the other and in the end both libraries will be loaded into the process. Additionally, a vndk can be an exact copy of the system ndk and both will still be loaded into the process (this is true on the Samsung S9).
As of now lldb is not able to distinguish one from the other due to a combination of relying solely on the module filename (instead of full path) and on the assumption that every library loaded into memory will have a different uuid.
You can see this by checking the memory regions of the running app, and see the 2 versions fo the same module loaded:
$ cat /proc/25047/maps | grep libcutils
c84dd000-c84e9000 r-xp 00000000 fd:00 3466 /system/lib/vndk-sp/libcutils.so
e5ba3000-e5baf000 r-xp 00000000 fd:00 2989 /system/lib/libcutils.so
$ md5sum /system/lib/libcutils.so /system/lib/vndk-sp/libcutils.so
On lldb you can see that there are 2 modules loaded but they actually point to the same file on disk and also the same memory region:
(lldb) image list libcutils.so
[ 0] 872E94B2-A24A-BF07-447E-ABE347E9D9F1 0xc84dd000 /Users/aadsm/.lldb/module_cache/remote-android/.cache/872E94B2-A24A-BF07-447E-ABE347E9D9F1/libcutils.so
[ 1] 872E94B2-A24A-BF07-447E-ABE347E9D9F1 0xc84dd000 /Users/aadsm/.lldb/module_cache/remote-android/.cache/872E94B2-A24A-BF07-447E-ABE347E9D9F1/libcutils.so
(lldb) script str(lldb.target.GetModuleAtIndex(5).GetPlatformFileSpec())
(lldb) script str(lldb.target.GetModuleAtIndex(233).GetPlatformFileSpec())
## The proposed fix
This fix happens in 3 different places:
The `qModuleInfo` packet was matching libraries by using only the filename and not the full path so it was always returning the same file path back.
I fixed this by making sure it checks the full path when the file received has a dirname.
This function is happy to match module specs purely based on the UUID, meaning that even if we have the right path from the server we still find a match against the wrong module spec.
I fixed this by checking the paths before the UUID. The UUID comparison first will probably be faster but I don't it's a big deal because `FileSpec::Equal` uses `ConstString` so it still should be just pointer comparison.
The module cache is being keyed by the UUID so again it will load the wrong Module even if we have the right module spec. To get around this I changed the cache key to be the module spec file spec path.