Yes, to do it right you should do that. I think it would still be worthwhile to first check whether the current frame’s source file is the one being asked for, since that is a very common way to get to source files and that would make going from source file -> module very cheap. But otherwise, I can’t see a way around finding the module the source file is actually used in and comparing times with that. Note, theoretically, you would also have to handle with the case where module A used an old version of the file and module B a new one - for instance when building two libraries with a common header file. Not sure what a good thing to do there is, maybe just warn?
Jim > On Apr 21, 2020, at 2:07 AM, Martin Schmidt via Phabricator > <revi...@reviews.llvm.org> wrote: > > n1tram1 added a comment. > > In D78421#1993030 <https://reviews.llvm.org/D78421#1993030>, @jingham wrote: > >> So you check the currently selected frame's module - which is libbar.dylib >> and find that it was built before FileFromNotBar.c and would show me the old >> version. >> >> Showing me the latest version of the file is not great, but totally >> explicable. Whereas this error, when it happens, would be confusing and >> hard to understand. > > > So instead I should try to find which module the source file belongs to and > check that module's modification time (instead of getting the currently > selected frame) ? > > > Repository: > rG LLVM Github Monorepo > > CHANGES SINCE LAST ACTION > https://reviews.llvm.org/D78421/new/ > > https://reviews.llvm.org/D78421 > > > _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
