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

Tue Aug 18 10:23:28 PDT 2015

| suggests that DW_TAG_imported_module could be used for C++ using directives (of which there are none in the source code in question).

[namespace.unnamed]/1 says there is an implicit (as-if) using directive.
--paulr

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Tuesday, August 18, 2015 10:15 AM
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.

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<mailto:dblaikie at gmail.com>> wrote:

On Tue, Aug 18, 2015 at 9:41 AM, Robinson, Paul <Paul_Robinson at playstation.sony.com<mailto: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<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<mailto:reviews%2BD7895%2Bpublic%2B7827be49c0b04087 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<mailto: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<mailto:dblaikie at gmail.com>]
Sent: Monday, August 17, 2015 6:16 PM
To: reviews+D7895+public+7827be49c0b04087 at reviews.llvm.org<mailto:reviews%2BD7895%2Bpublic%2B7827be49c0b04087 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<mailto: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<mailto: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/473d5c79/attachment.html>