labath added a comment. 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 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
