JDevlieghere added a comment. In D65611#1611724 <https://reviews.llvm.org/D65611#1611724>, @labath wrote:
> The details of how our FS capture works have unfortunately, swapped out of my > memory, but... isn't this the sort of thing that should already be handled by > the filesystem capture/replay machinery? It sounds to me like it could/should > remember what the CWD at the time of capture was, and then, when replaying, > point the fake CWD into the right place in the captured filesystem image. > This way, the relative paths should resolve the same way as they originally > did. This functionality is not currently present in the VFS, but I've created a patch to support it: https://reviews.llvm.org/D65677 > This patch just moves the place where this VFS definiciency manifests itself > (*), so that it does not pose a problem for this particular use case. > However, I'd be surprised if this is the only relative path that is being > resolved inconsistently, and I think a more general solution would be more > appropriate. > > (*) What I mean by that, is that the `SBFileSpec::ResolvePath` will still end > up returning a different value during replay than what it did originally. > However, because the data leaves the SB boundary, and then crosses it back in > through SBStream::Printf, we lose track of the fact that this is the same > data, and we capture it as a constant. Before this patch, the data was always > under the SB boundary, and so we were assuming that the data flow will be > identical during record&replay, which it wasn't, and that is the real bug, I > think. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D65611/new/ https://reviews.llvm.org/D65611 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
