<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 17, 2015 at 7:07 PM, Robinson, Paul <span dir="ltr"><<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">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. </span></p></div></div></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">
 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.)</span></p></div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">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.</span></p></div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> </span><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt">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. </span></p></div></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> Clients *are* expected to understand the target platform.</span> </p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">To recap: An artificial import of a C++ anonymous namespace conforms to DWARF's intent, and having it be target-dependent is silly.</span></p></div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">--paulr<u></u><u></u></span></p>
<p class="MsoNormal"><a name="14f3e8fa75f8c94e__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></a></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> David Blaikie [mailto:<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>]
<br>
<b>Sent:</b> Monday, August 17, 2015 6:16 PM<br>
<b>To:</b> <a href="mailto:reviews%2BD7895%2Bpublic%2B7827be49c0b04087@reviews.llvm.org" target="_blank">reviews+D7895+public+7827be49c0b04087@reviews.llvm.org</a>; Robinson, Paul<br>
<b>Cc:</b> Romanova, Katya; Eric Christopher; Frédéric Riss; Duncan P. N. Exon Smith; llvm-commits<br>
<b>Subject:</b> Re: [PATCH] D7895: Anonymous namespaces are missing import DW_TAG_imported_module.<u></u><u></u></span></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Aug 17, 2015 at 6:12 PM, Paul Robinson via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:<u></u><u></u></p>
<p class="MsoNormal">probinson added a comment.<br>
<br>
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.<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">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.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
<br>
<a href="http://reviews.llvm.org/D7895" target="_blank">http://reviews.llvm.org/D7895</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div></div></div>
</div>
</div>

</blockquote></div><br></div></div>