<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 29, 2016 at 10:48 AM, Teresa Johnson <span dir="ltr"><<a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Fri, Jan 29, 2016 at 8:33 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Jan 29, 2016 at 5:47 AM, Teresa Johnson via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">tejohnson added a comment.<br>
<span><br>
> > I think so. At least for composite types. Are there any cases, other than from the retainedTypes list on the compile unit, where a DICompositeType node is referenced by its address rather than by UUID?<br>
<br>
><br>
<br>
><br>
<br>
> Try types without a mangled name - I suppose one example might be something like:<br>
<br>
><br>
<br>
> a.cpp:<br>
<br>
>  void b();<br>
<br>
>  int main() {<br>
<br>
><br>
<br>
>   b();<br>
<br>
><br>
<br>
> }<br>
<br>
><br>
<br>
> b.cpp:<br>
<br>
>  namespace {<br>
<br>
>  struct anon {<br>
<br>
>  };<br>
<br>
>  void bimpl(anon) {<br>
<br>
>  }<br>
<br>
>  }<br>
<br>
>  void b() {<br>
<br>
><br>
<br>
>   bimpl(anon());<br>
<br>
><br>
<br>
> }<br>
<br>
><br>
<br>
> If bimpl is imported into a (presumably after b is imported into a) then you'll see a type without a mangled name... what you should do with this is perhaps a difficult question. A debugger's going to have a hard time identifying these types (or even the two 'bimpl' functions) as the same when they're in two different object files & flagged as being "local" entities...<br>
<br>
<br>
</span>Confirmed that in this case, the composite type for anon is in the subroutine type list for bimpl, and that when we import bimpl into a.cpp we therefore import the full composite type definition.<br>
<br>
It isn't clear to me from your last sentence what we should do here. Does having the full type definition imported make it easier or harder for the debugger?<br></blockquote></span><div><br>(probably as Duncan said, there's nothing else we can really do here other than to have the full type definition imported)<br></div></div></div></div></blockquote><div><br></div></span><div>Ok, thanks, that's what happening with this patch so that's good.</div><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>As for what debuggers will do with this - I'm not really sure. I think it'll hurt users a little bit, but don't know of any way to improve that off hand.<br><br>(what I'm thinking might happen is that, when the user is evaluating expressions within the context of the Compilation Unit that imported a local function (or non-local function using a local type, not sure how we emit that, maybe it still looks like a local function) from another CU, it'll find the imported local, probably discover that it has no definition (because it was only imported for inlining, etc - the definition would never be emitted here), and be unable to call it in the expression evaluator because it wouldn't know that the local function in another CU is the same function)<br><br>Not sure whether local types would present the same/similar issues - they could introduce strange name lookup situations for example:<br><br>a.cpp:<br>namespace a {<br>namespace {<br>struct foo { int a; };</div><div>}<br>}<br>void f1() {<br>  a::foo f;<br>}</div><div><br></div><div>b.cpp:<br>namespace {<br>struct foo { float b; };</div><div>}<br>namespace a {<br>void f2() {<br>  f1();<br>  foo f;</div><div>}<br>}<br><br>f1 is imported into the b.cpp module, along with the types necessary to describe it.<br><br>So now b.cpp's debug info looks like this:<br>namespace {<br>struct foo { float b; };<br>}</div><div>// f1<br>namespace a {<br>struct foo { int a; };<br>void f2() {<br>  f1();<br>  foo f; // but miraculously, this 'foo' refers to ::foo, not a::foo<br>}</div><div>}<br><br>Now if the user is in the expression evaluator in f2 and refers to 'foo', the debugger will find a::foo, even though the user is staring at code that uses the unqualified 'foo' to refer to ::foo<br></div></div></div></div></blockquote><div><br></div></div></div><div>What happens in an LTO build in this case? Will it be similarly confused? If not, how does it handle this case since all the types are being merged?</div></div></div></div></blockquote><div><br></div><div>In a full LTO, I /think/ what we do at the moment is cross-CU references (or at least I remember that being done on MacOS by Adrian/Duncan/etc - but I think it happens generally/cross-platform). So the anonymous type remains in one CU in the DWARF, and the function in another CU can refer to it... (not sure if we do that for the inlined functions themselves - have the inline instance refer, cross-CU to the abstract instance in the right CU, I don't think so)<br><br>Not sure what debuggers do with that, but it's somewhat more informative and they /could/ do the right thing.<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Thanks,</div><div>Teresa</div><span class=""><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br>I don't expect this sort of thing to be terribly common - but it's seems technically possible to produce awkward debugging situations when importing file-local entities. ("benign" violations of the ODR may cause other problems, but our type uniquing by mangled name will probably already break those in LTO at least, FWIW)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thanks,<br>
Teresa<br>
<br>
><br>
<br>
><br>
<br>
> - Dave<br>
<div><div><br>
<br>
<br>
<a href="http://reviews.llvm.org/D16440" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16440</a><br>
<br>
<br>
<br><span>
_______________________________________________<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
</span></div></div></blockquote></div><br></div></div>
</blockquote></span></div><br><br clear="all"><span class=""><div><br></div>-- <br><div><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> <a href="tel:408-460-2413" value="+14084602413" target="_blank">408-460-2413</a></td></tr></tbody></table></span></div>
</span></div></div>
</blockquote></div><br></div></div>