<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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 class=""><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><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><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><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 class="HOEnZb"><div class="h5"><br>
<br>
<br>
<a href="http://reviews.llvm.org/D16440" rel="noreferrer" target="_blank">http://reviews.llvm.org/D16440</a><br>
<br>
<br>
<br>
_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org">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>
</div></div></blockquote></div><br></div></div>