Michael137 wrote: > Sounds like a nice feature to have. I'm not really familiar with these APIs, > so I don't have much to say in the way of specifics. One high level question > I have (I can't tell from the patch) is how are these files actually handled. > Do we need to (preemptively) read them into some clang-owned buffer, or can > we say something like "there is a file here, come back to me if you need it". > I have two reasons for asking this: I'm wondering if this will have any > impact on our memory footprint; and I'm wondering how will this behave if the > file is changed (or deleted) during the course of the debug session.
Yea I wasn't sure what the best answer to this is yet. Currently we create a `SourceLocation` (which is just a compact <`FileID`, `offset`> pair, where `offset` is the position into the file) using `translateLineCol`, which will mmap the file if we haven't done so yet, and then calculate the offset based on the line/column info. > "there is a file here, come back to me if you need it" >From my limited understanding of these APIs, I don't think there's currently >such a customization point. LLDB would have to somehow store that column/line >info somewhere until Clang asks for it. We could maybe stuff >`FileID`+`column`+`line` into the `SourceLocation`, and steal bit as an >indicator that this is a "lazy source location"? I'd have to investigate this >a bit more. But I guess we'd have to decide whether opening the source files is an unacceptable increase in the memory footprint for the common debugging use-case. I can collect some memory usage numbers when debugging clang/lldb as one data-point https://github.com/llvm/llvm-project/pull/127829 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
