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

Tue Aug 18 09:12:26 PDT 2015

> On Aug 17, 2015, at 7:40 PM, David Blaikie via llvm-commits <llvm-commits at lists.llvm.org> wrote:
> 
> 
> 
> 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)

If they are different — is it possible to construct a counterexample where importing the anonymous namespace would break ADL? 

>  
> 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.
> 
I think that if the artificial import is actually harmful (as in breaking ADL, etc) that would be a clear argument against doing this. If it is harmless redundant information, we should discuss having this as a debugger tuning option. But it is also worth noting that the DWARF standard currently comes with a (non-normative) example for handling C++ namespaces (D.26) that does have an anonymous namespace in it but no explicit import of said namespace.

-- adrian

>  
> 
> --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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D7895&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=cTx6f1tAfqPeajYunFWp7_8ot79RnHyNteqzig4fXmA&m=D7BY3Vxyq-eiSHVxQzbo9qzh1Pc3OE1N4ni8ImjNODU&s=_lVvuuzut1TIR6SRYmhflCLAsW2aZiD8gJ2A-YmOmu4&e=>
> 
> 
> 
> _______________________________________________
> 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=BQMFaQ&c=eEvniauFctOgLOKGJOplqw&r=cTx6f1tAfqPeajYunFWp7_8ot79RnHyNteqzig4fXmA&m=D7BY3Vxyq-eiSHVxQzbo9qzh1Pc3OE1N4ni8ImjNODU&s=wW2qE3rJYtnhkcCjbFaeTqs2qzkeBASQTJgCnX-hcCk&e=>
>  
> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at lists.llvm.org
> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=cTx6f1tAfqPeajYunFWp7_8ot79RnHyNteqzig4fXmA&m=D7BY3Vxyq-eiSHVxQzbo9qzh1Pc3OE1N4ni8ImjNODU&s=wW2qE3rJYtnhkcCjbFaeTqs2qzkeBASQTJgCnX-hcCk&e= <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_llvm-2Dcommits&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=cTx6f1tAfqPeajYunFWp7_8ot79RnHyNteqzig4fXmA&m=D7BY3Vxyq-eiSHVxQzbo9qzh1Pc3OE1N4ni8ImjNODU&s=wW2qE3rJYtnhkcCjbFaeTqs2qzkeBASQTJgCnX-hcCk&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150818/574fde9a/attachment.html>