[Lldb-commits] [PATCH] D65611: [Driver] Expand the target in the driver.

Jonas Devlieghere via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Fri Aug 2 14:30:21 PDT 2019


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





More information about the lldb-commits mailing list