labath added a comment. In D62316#1515266 <https://reviews.llvm.org/D62316#1515266>, @labath wrote:
> In D62316#1513905 <https://reviews.llvm.org/D62316#1513905>, @clayborg wrote: > > > In D62316#1513894 <https://reviews.llvm.org/D62316#1513894>, @labath wrote: > > > > > Two other options I see are: > > > > > > - initialize the sections immediately after creating the dwarf context. > > > The main advantage of that would that it alings to code more with llvm > > > (which also loads the sections up-front), and slighly faster subsequent > > > accesses to the debug info. I don't think this should negatively impact > > > the start up time, as the files are mmapped anyway, and so the "loading" > > > will consist of some basic pointer arithmetic. Also, the SymbolFileDWARF > > > object as a whole is created lazily, so the fact that it is being created > > > means that somebody is going to access it immediately after that. And he > > > cannot do anything with the symbol file without touching at least the > > > debug_info section, which accounts for about 80% of all debug info. > > > > > > I'd be fine with this. > > > Ok, so let's go with the current solution to restore status quo, and I'll > return to this idea later. I've realized that this may negatively affect the modules which are being read from process memory (this does not really work for ELF or PECOFF, but MachO implements it, and loads sections lazily). Given that it also seems to be possible to create the llvm DWARFContext with a custom implementation of DWARFObject (which could probably implement lazy loading, if needed), this does not seem to be that important right now. So, I've decided to shelve the idea for the time being. Repository: rLLDB LLDB CHANGES SINCE LAST ACTION https://reviews.llvm.org/D62316/new/ https://reviews.llvm.org/D62316 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
