[Lldb-commits] [PATCH] D48393: Make DWARFParsing more thread-safe

[Jim Ingham via lldb-commits]

> On Jun 22, 2018, at 4:05 AM, Pavel Labath <labath at google.com> wrote:
> 
> On Wed, 20 Jun 2018 at 23:21, Jim Ingham <jingham at 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.

Jim