jasonmolenda added a comment. In D108889#2973300 <https://reviews.llvm.org/D108889#2973300>, @clayborg wrote:
> So do the shared library files on disk that are exploded from a shared cache > of an iOS device have the file addresses set to where they are in the shared > cache? I am guessing this must the issue that you were running into where the > module was not in memory by still it needed to have its file addresses > adjusted. Yes, when a shared cache is expanded into discrete binaries, they still have the file addresses from the shared cache. So a dylib starts with file address based at 0, then it gets a new file address when incorporated into the shared cache, and then when expanded out of the shared cache, it retains the non-zero base file address. But also on macOS now, it behaves like iOS where the binaries don't exist on the filesystem any more, they only exist in the shared cache blob / in memory. When the lldb process & the inferior process are using the same shared cache (99% of the time this is true), lldb creates ObjectFiles in its own address space for the shared cache binaries. That's where this bug was especially hitting. Adding a log message here is a good idea. > Besides some indentation, and possibly logging when we modify the file > address, this LGTM. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108889/new/ https://reviews.llvm.org/D108889 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
