On Fri, 22 Jun 2018 at 18:42, Jim Ingham <jing...@apple.com> wrote: > > > > > On Jun 22, 2018, at 4:05 AM, Pavel Labath <lab...@google.com> wrote: > > > > On Wed, 20 Jun 2018 at 23:21, Jim Ingham <jing...@apple.com> wrote: > >> > >> It is not uncommon that you would be parsing the DWARF for module A and > >> find a type that is only known as a forward declaration. In that case, > >> lldb will look through the other Modules' debug info for a real > >> definition, parse that and import it into module A. So you would need to > >> suspend one task, start another and wait on its completion. > >> > > > > Taking a step back, I was wondering what are the situations when we do > > this kind of cross-module debug info importing? I was under the > > impression that we don't do this kind importing precisely because the > > module can be shared between multiple targets (and we don't want > > information from a module which is not loaded in a given target to > > leak into it just because we happen to have a different target with > > that module around). I think these kinds of things came up during the > > discussions about why lldb behaves poorly under -fno-standalone-debug. > > > > Am I misunderstanding something here? Because if this is true (parsing > > debug info in a given module does not access other modules), then > > maybe we could solve this by just taking some kind of a module lock > > when parsing debug info in the given module. > > We only do this when we are parsing DWARF on behalf of the expression > parser's AST context. That context is not shared among targets, so it > doesn't cause the sort of problems you are worried about. The target AST > context looks in itself for definitions and then dispatches to the module's > AST contexts to look for, parse and import into itself definitions it doesn't > know or hasn't completed yet. I don't remember whether we pause mid-stream > to find unknown types in this case, or do it as a cleanup. I haven't looked > at that code in years. Greg probably remembers it better than I do. > > Note, it is in fact a longstanding bug that, if you are in a frame of a > module that only has a forward declaration of type Foo, which exists in full > in another module, "expr" will helpfully print the full type, but "frame var" > will not. That's tricky to solve for the reasons you specify. The target > would need to keep a per-module side table of types that augment the ones in > the modules and use that somehow. It's not clear how to make this work, and > the bug has languished for most of the life of lldb... But it is not good > for the debugger to have two ways to print values - both of which are in > common usage because the "frame variable" path is how all GUI debuggers > present local variables - which give different answers for the same value. > So I still think the bug is important, and I don't want to make this more > difficult. OTOH, however we solve it, the target-inferred extra types can't > go into the Module based AST contexts for the reasons you outline, so it > seems like a good assumption that if you are parsing module A, that can't > cause you to parse module B. But we might have to introduce some more > distinctions between how we ingest DWARF for the scratch AST contexts and for > the module AST contexts.
Thanks for the detailed explanation! I think this sounds like a promising direction then. Having a per-module lock for a per-module AST context should be much more understandable than some kind of multithreaded deadlock-free lazy evaluation system. _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
