labath added a comment. In D113789#3133205 <https://reviews.llvm.org/D113789#3133205>, @clayborg wrote:
> In D113789#3130741 <https://reviews.llvm.org/D113789#3130741>, @labath wrote: > >> Maybe it's good for starting a discussion, but I am surprised that we would >> need to cache symtab information. This is a fairly simple format that needs >> to be read at application runtime as well, so I am surprised that reading it >> from the cache is substantially faster than doing it from the object file. >> What is the slow part there? Is it demangling by any chance? > > Symbol tables for LLDB are made up by scouring every bit of data we can out > of one or more symbol tables (ELF has normal symbol table and the dynamic > symbol table, and optionally the symbol table in the zipped debug info). > There are also many runtime sections like .eh_frame and [...] Ok, you've convinced me. :) I completely forgot about all the things that go into these. >> Now to the discussion. Overall, I think this is an interesting feature, but >> I do have some remarks/questions: >> >> - I don't think that "lldb module cache" is very good name for this feature >> as we already have the "platform module cache" feature (see >> `Target/ModuleCache.h` and its callers), which deals with downloading (and >> caching) modules (object files) from remote systems. And then there's the >> clang module cache, of course.. (and the llvm modules, but we fortunately >> don't cache those). It would be better if we chose a slightly less >> overloaded name. Maybe "index cache" ? (I assume you will also want to store >> dwarf indexes there) > > yes debug info is the next item I want to put into this cache. "index cache" > sounds fine. I will rename once I get a few NFC patches submitted and rebase. > >> - I don't see anything which would ensure cache consistency for the case >> where multiple debugger instances try to cache the same module >> simultaneously. What's the plan for that? > > I was hoping to learn LLVM already had this kind of thing and using that! I > see below there are some things already in LLVM I should be able to use. > >> - Have you considered the building upon the caching infrastructure in llvm >> (`llvm/Caching.h`, `llvm/CachePruning.h`)? I believe it already has some >> size limiting features and multiprocess synchronization built-in, so using >> it would take care of the previous item, and of @wallace's size limit >> request. > > I will check into that and see if I can use that! I figured it would have > been done already, glad to see it has! Cool. Thanks. >> - it's moderately strange to be using the gsym file writer for this purpose > > When I made gsym I create the FileWriter as something that can easily create > binary content without having to go with the ASM print/writer stuff in LLVM > as that requires tons of stuff including LLVM targets and object file support. > > What suggestions do people have on this front? Should I make a patch to move > FileWriter out of GSYM? I don't know how if llvm::gym::FileWriter is useful > enough for other folks in LLVM. Any thoughts? Should we just make our own > FileWriter class that only does what we need for the caching? Is there any > other tech in LLVM that does this kind of thing without having to use the > full ARM printer/writer stuff? The binary writing capabilities in llvm mostly take form of various free functions instead of a single rule-them-all class. This makes it hard to discover, which is probably the reason for the existence of gsym::FileWriter-type classes (the ObjectYAML library also has things like that.) For binary endian-specific writing, there's llvm::endian::Writer in `llvm/Support/EndianStream.h`. It doesn't have anything fancy, but I don't think we need anything fancy here. The biggest thing it lacks is the ability to write a null-terminated string. We could make another free function for that, or maybe even add it to the raw_ostream interface (next to `write_zeroes`). I don't think you need them here, but there are [US]LEB128 writing functions in `llvm/Support/LEB128.h`. We also have a DataEncoder class on the lldb side. It has (or could be made to have) all the writing capabilities you need, but it's not an exact fit because it's currently writing to a memory buffer. However, it only has a handful of uses, so I could imagine rafactoring it to work with `raw_ostream`s instead. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D113789/new/ https://reviews.llvm.org/D113789 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
