[Lldb-commits] [lldb] [WIP] [lldb][TypeSystemClang] Create clang::SourceLocation from DWARF and attach to AST (PR #127829)

Michael Buch via lldb-commits lldb-commits at lists.llvm.org
Fri Feb 21 07:40:05 PST 2025


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


More information about the lldb-commits mailing list