Performance i get. Gdb is almost unusable for large programs because of how long it takes to load debug info.
Do you have specific numbers on memory usage? How much memory (absolute and %) is saved by loading debug info lazily on a relatively large project? On Thu, Jun 21, 2018 at 7:54 AM Greg Clayton <clayb...@gmail.com> wrote: > > > On Jun 21, 2018, at 7:47 AM, Zachary Turner <ztur...@google.com> wrote: > > Related question: Is the laziness done to save memory, startup time, or > both? > > > Both. It allows us to fetch only what we need when we need it. Time to > break at main.cpp:123 is much quicker. Using LLDB for symbolication is much > quicker as symbolication only needs to know about function definitions and > function bounds. Many uses of LLDB are made better by partially parsing. > > On Thu, Jun 21, 2018 at 7:36 AM Greg Clayton via Phabricator < > revi...@reviews.llvm.org> wrote: > >> clayborg added a comment. >> >> In https://reviews.llvm.org/D48393#1138989, @labath wrote: >> >> > I am not sure this will actually solve the problems you are seeing. >> This may avoid corrupting the internal DenseMap data structures, but it >> will not make the algorithm using them actually correct. >> > For example the pattern in `ParseTypeFromDWARF` is: >> > >> > 1. check the "already parsed map". If the DIE is already parsed then >> you're done. >> > 2. if the map contains the magic "DIE_IS_BEING_PARSED" key, abort >> (recursive dwarf references) >> > 3. otherwise, insert the "DIE_IS_BEING_PARSED" key into the map >> > 4. do the parsing, which potentially involves recursive >> `ParseTypeFromDWARF` calls >> > 5. insert the parsed type into the map >> > >> > What you do is make each of the steps (1), (3), (5) atomic >> individually. However, the whole algorithm is not correct unless the whole >> sequence is atomic as a whole. Otherwise, if you have two threads trying to >> parse the same DIE (directly or indirectly), one of them could see the >> intermediate DIE_IS_BEING_PARSED and incorrectly assume that it encountered >> recursive types. >> >> >> We need to make #1 atomic. >> #2 would need to somehow know if the type is already being parsed >> recursively by the current thread. If so, then do what we do now. If not, >> we need a way to wait on the completion of this type so the other parsing >> thread can complete it and put it into the map, at which time we grab the >> right value from the map >> So #6 step would need to be added so after we do put it into the map, we >> can notify other threads that might be waiting >> >> > So, I think that locking at a higher level would be better. Doing that >> will certainly be tricky though... >> >> >> >> >> https://reviews.llvm.org/D48393 >> >> >> >> >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
