[PATCH] D7895: Anonymous namespaces are missing import DW_TAG_imported_module.

Tue Aug 18 10:15:22 PDT 2015

All I'm saying is that I think this is a fine thing to have as a
debugger-specific tuning for your debugger.

DWARF-the-standard is language neutral, yes, so it provides features that
can be used to describe many different languages. It describes
(non-normatively) possible uses of DWARF features for language features,
and suggests that DW_TAG_imported_module could be used for C++ using
directives (of which there are none in the source code in question). It
doesn't suggest anywhere that it should, let alone must, be used to
explicitly describe name lookup rules (or we'd need those using directives
in nested scopes for all outer scopes, for example).

On Tue, Aug 18, 2015 at 10:07 AM, David Blaikie <dblaikie at gmail.com> wrote:

>
>
> On Tue, Aug 18, 2015 at 9:41 AM, Robinson, Paul <
> Paul_Robinson at playstation.sony.com> wrote:
>
>> If you want to be super pedantic, yes the entities themselves are not in
>> the outer scope—that's why they need to be imported—but their names are
>> available in the outer scope.
>>
>>
>>
>> Whether the client knows to peek into an inner scope is not a
>> quality-of-implementation issue, it's a "does DWARF require the client to
>> know a particular language rule" issue.
>>
>
> I don't really understand the distinction you are drawing. If the DWARF
> client doesn't know the particular language rule, the client will be of
> lower quality because it won't provide/expose/etc names that it otehrwise
> could/should.
>
>
>>   And my answer is No, DWARF does not require that.  There are other
>> examples like this:  DWARF does not require the client to be aware of a
>> language's case-sensitivity rule; it's explicit.  DWARF does not require
>> names to be unique.  DWARF does not require names to follow a language's
>> "identifier" rules.
>>
>> There's the case of the default lower-bound for arrays, but that's not
>> implicitly something the client is supposed to be aware of; the DWARF spec
>> explicitly makes it language-dependent.  There's no such language-dependent
>> rule (and there never will be) for implicitly importing anonymous
>> namespaces into the containing scope, because you get exactly the right
>> effect with an explicit import.  DWARF has the feature you need and it's a
>> trivial size cost.
>>
>>
>>
>> I don't think I would say "DWARF debuggers use language-specific
>> knowledge" to look in outer scopes. Every language I'm aware of, except one
>> and then only in some cases, behaves that way.  When I was proposing DWARF
>> features for other stuff COBOL needed, I deliberately didn't do anything
>> about the older (obsolescent) scoping rules; our debugger just got it
>> wrong, and nobody cared.
>>
>
> OK, sorry - I assumed when you gave the example, that there existed
> debuggers that behaved correctly under those constraints.
>
> "DWARF debuggers use language specific knowledge, or are wrong" (the same
> would go for Clang's output, it seems directly analogous)
>
>
>>   I can't say the same would be true about failing to handle anonymous
>> namespaces correctly, but there's an existing obvious DWARF feature to make
>> sure they are handled correctly, and we should just use it.
>>
>
> It could've been used for every language other than COBOL - forcing them
> to import every outer namespace into the inner ones. But isn't. This seems
> rather arbitrarily inconsistent.
>
>
>>  Bringing up ADL is not particularly to the point; again, how the client
>> chooses to let the user select an entity, out of all those available
>> (pedantically, all those whose names are available) in a given scope, is a
>> different thing than specifying the available set.  For example, a debugger
>> whose GUI has the available names for a scope in a pick list (with
>> drill-downs for components of an aggregate; man that was nice).  ADL is
>> clearly irrelevant in that case, and having the explicit import made
>> constructing the pick lists totally language-independent.
>>
>
> Usually (well, at least in C++) those picklists (if I'm thinking of the
> right UI - like autocomplete in Visual Studio) reduce the overload set as
> you type arguments in and they do type checking on the fly. They'd still
> want to model ADL in that case to get more accurate behavior for the user.
>
>
>>  Re. calling conventions, whether a particular formal parameter to a
>> function expects to be passed by value or reference/pointer is obviously
>> explicit in the DWARF (DW_AT_type), as is whether it is passed in a
>> register (DW_AT_location).  I'm not at all sure what you're getting at with
>> this argument.
>>
>
> Sorry I wasn't clear - I was referring to the ABI lowering of C++ by value
> parameters.
>
> struct foo { foo(const foo&); int i; };
> struct bar { int i; };
> void func(foo, bar) { }
>
> foo and bar are passed quite differently in the ABI
>
>
>>  Oh, unless you're thinking about it in the context of the debugger
>> allowing you to type in an arbitrary current-language-syntax expression and
>> evaluate it as a sort of mini-compiler given a particular source-point
>> context?  I can't imagine DWARF imposing that feature-laden a debugger as a
>> minimum necessary client.
>>
>
> I don't think it's a minimum bar necessary for a debugger - but it's
> certainly a pretty basic debugger feature. I just want to print the result
> of calling this function - seems to happen pretty frequently. DWARF
> currently (but hopefully that's changing) doesn't do anything to help the
> debugger here, and the debugger has to reconstruct the language rules that
> were applied to figure out how to pass foo and bar.
>
>
>> DWARF is not an AST.
>>
>> --paulr
>>
>>
>>
>> *From:* David Blaikie [mailto:dblaikie at gmail.com]
>> *Sent:* Monday, August 17, 2015 7:40 PM
>> *To:* Robinson, Paul
>> *Cc:* reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org; Romanova,
>> Katya; Eric Christopher; Frédéric Riss; Duncan P. N. Exon Smith;
>> llvm-commits
>>
>> *Subject:* Re: [PATCH] D7895: Anonymous namespaces are missing import
>> DW_TAG_imported_module.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Aug 17, 2015 at 7:07 PM, Robinson, Paul <
>> Paul_Robinson at playstation.sony.com> wrote:
>>
>> DWARF describes a mapping from source to object.  It tries to use
>> language-neutral mechanisms to do this.  "Namespace" is not a C++-specific
>> notion.  "Importing" a name or set of names from one scope to another is
>> not a C++-specific notion.  Emitting an artificial import seems like a
>> perfectly natural way to translate the C++ language-specific rule about
>> anonymous namespaces into a language-neutral DWARF description.
>>
>>
>>
>> This is not about how to let a user identify an entity available within a
>> scope; this is about what entities are available within the scope in the
>> first place.
>>
>>
>>
>> I'm not sure I really understand the distinction, or perhaps how it
>> applies here... The entities within an anonymous namespace are not /in/ the
>> outer namespace, they're able to be found there (those are different things
>> - see the recent discussion around how to make an equivalent std::copy in
>> LLVM without breaking existing calls due to ADL - putting a name in another
>> namespace, then importing it from that namespace has different ADL effects)
>>
>>
>>
>> The artificial import gives you that.  Failing to provide the import
>> imposes a *requirement* on the client to understand language-specific
>> scope-munging rules, in order for the client to even know what entities are
>> available.  DWARF tries hard not to impose that kind of requirement.
>> (DWARF does assume that inner scopes can see all entities in outer scopes,
>> which is how most but not all languages work.  COBOL's data-visibility
>> rules are really arcane.)
>>
>>
>> This seems like it would support my position - Your COBAL example tells
>> me that DWARF debuggers use language-specific knowledge to know to look in
>> outer scopes for names without qualification. We don't expect the frontend
>> to emit an imported module into each nested namespace that imports the
>> outer one to model the name lookup of C++ in this case.
>>
>>
>>  Regarding ADL, it is not a DWARF-imposed requirement that every
>> debug-info client understand all the C++-defined shorthand methods for
>> identifying an entity.  While could be very user-friendly of the client to
>> permit users to type in C++-like syntax to name things, and disambiguate
>> them for you, that depends on the client's UI and at most is a
>> quality-of-implementation issue for the client, not something assumed or
>> imposed (and certainly not required) by DWARF.
>>
>>
>> Again, then the same logic applies to the imported name - it's a quality
>> of implementation issue for the client if it chooses not to implicitly look
>> into anonymous namespaces.
>>
>>
>>  Regarding calling conventions, a lot of the relevant information is
>> actually explicit in the DWARF, and (without having thought about it much)
>> I expect what's implicit would be platform-dependent not
>> language-dependent.
>>
>>
>>
>> Sorry, I had in mind all the arcane rules about pass by value versus pass
>> by pointer depending on a type's trivial copyability. Also the rules about
>> which parameters are passed in registers (which is language-dependent to a
>> degree - see the ABI support in Clang - choosing how to lower C++ function
>> into LLVM functions to correctly communicate the ABI: splitting structs
>> into single variables if the struct is trivially copyable, etc). again for
>> (trivial and non-trivial) return values. It seems there's been a strong
>> push (as I hear it) not to encode the ABI (which, especially in C++'s case,
>> is certainly a language issue - see the Itanium ABI/cxx-abi project).
>> Granted that's changed a bit recently, if I hear correctly, that Richard's
>> arguments for triviality (upon finding a GCC bug where it incorrectly
>> computed triviality & messed up the calling convention/produced bad calls)
>> being impossible for consumers to compute correctly in a reliable manner
>> seems to have been heard/understood.
>>
>>
>>
>> Clients *are* expected to understand the target platform.
>>
>>
>>
>> To recap: An artificial import of a C++ anonymous namespace conforms to
>> DWARF's intent, and having it be target-dependent is silly.
>>
>>
>>
>> --paulr
>>
>>
>>
>> *From:* David Blaikie [mailto:dblaikie at gmail.com]
>> *Sent:* Monday, August 17, 2015 6:16 PM
>> *To:* reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org; Robinson,
>> Paul
>> *Cc:* Romanova, Katya; Eric Christopher; Frédéric Riss; Duncan P. N.
>> Exon Smith; llvm-commits
>> *Subject:* Re: [PATCH] D7895: Anonymous namespaces are missing import
>> DW_TAG_imported_module.
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Aug 17, 2015 at 6:12 PM, Paul Robinson via llvm-commits <
>> llvm-commits at lists.llvm.org> wrote:
>>
>> probinson added a comment.
>>
>> I don't think this should be PS4-special.  I know I was more wishy-washy
>> about it before, but really DWARF-the-standard tries to be
>> language-neutral.  Emitting an explicit import matches the intent of DWARF,
>> and Clang should always do it.
>>
>>
>>
>> I don't quite see how "DWARF the standard tries to be language neutral"
>> and "DWARF should model the source" are resolved here... the source is an
>> anonymous namespace, without any using directive. In the same way that
>> DWARF clients figure out calling conventions (and name lookup rules for
>> other entities - including complex things like ADL) based on the language,
>> so would this, I would think.
>>
>>
>>
>>
>>
>> http://reviews.llvm.org/D7895
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150818/f3915e96/attachment.html>