<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Feb 17, 2014, at 10:26, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 10:16 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
On Feb 15, 2014, at 17:25, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
<br>
> On Sat, Feb 15, 2014 at 2:57 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
>> So when comparing Clang's debug info strings to GCC's I came across a couple<br>
>> of disparities hinging on the inclusion of linkage names on certain<br>
>> functions. Here are a few differences:<br>
>><br>
>> * Clang includes linkage names on file-local (static or anon namespace)<br>
>> functions. GCC does not.<br>
>> * Clang does not include the linkage name of member functions of<br>
>> function-local classes. GCC does, if the function is<br>
>> non-static/non-anonymous namespace and inline (ie: the member function has<br>
>> linkonce-odr linkage, not internal linkage)<br>
>> * Clang does not include the linkage name for constructors and destructors -<br>
>> this may be necessary due to the difference (GCC duplicates, Clang has one<br>
>> version call the other) in implementations, but I doubt it. I assume we<br>
>> still emit multiple member functions, one to describe each version of the<br>
>> ctor/dtor we're emitting.<br>
>><br>
>> It looks like at least for the first case, this may've been deliberate (<br>
>> <a href="http://llvm.org/viewvc/llvm-project?view=revision&revision=154570" target="_blank">http://llvm.org/viewvc/llvm-project?view=revision&revision=154570</a> which<br>
>> doesn't explain why and points to <a href="rdar://11079003">rdar://11079003</a> which Jim Grosbach told<br>
>> didn't have a great deal more context) but I don't have enough context to<br>
>> understand why and whether it's just a GCC bug that they don't emit it, or<br>
>> something tools should handle better, etc.<br>
>><br>
>> So - any thoughts on the disparity and if/why it's necessary?<br>
>><br>
><br>
> My thought is that it is basically there to assist in lookup of<br>
> symbols. I put the earlier patch in because it was seen as useful<br>
> there. In general I find that mangled names are helpful on any entity<br>
> that we might want to put into a lookup table since we might have a<br>
> qualified name that we'd like to look up. I doubt that any<br>
> discrepancies here are intentional, but that any time we have a<br>
> mangled name we probably want to add it.<br>
<br>
</div></div>And regarding the change r154570, the summary of that radar is that there was a mangled name for a static function in the symbol table, but the debugger could not look it up in the DWARF because the mangled name was not mentioned there.</blockquote>
<div><br>Could you try a similar experiment with a constructor/destructor (we don't emit linkage_name for them, but GCC does) and with member functions of function-local classes (both in an inline/linkonce-odr function and an external linkage function - GCC would only put the linkage_name on the former, not the latter, I believe (because the former's member function has linkonce-odr linkage and the latter should be internal linkage))?<br>
<br>It'd be nice to get these things consistent.<br></div></div></div></div></blockquote></div><br><div>What exactly would you like me to test?</div><div>What I tried so far (setting breakpoints on those symbols in lldb) confirms what Greg said earlier — qualified lookups for functions that don’t have a linkage name fail:</div><div><br></div><div><div style="margin: 0px; font-family: Menlo;">(lldb) b A</div><div style="margin: 0px; font-family: Menlo;">Breakpoint 8: 2 locations.</div></div><div style="margin: 0px; font-size: 14px; font-family: Menlo;"><div style="margin: 0px; font-size: 12px;">(lldb) b ~A</div><div style="margin: 0px; font-size: 12px;">Breakpoint 7: 2 locations.</div><div style="margin: 0px; font-size: 12px;">(lldb) b A::A</div><div style="margin: 0px;"><div style="margin: 0px; font-size: 12px;">Breakpoint 6: no locations (pending).</div><div style="margin: 0px; font-size: 12px;">WARNING: Unable to resolve breakpoint to any actual locations.</div><div style="margin: 0px; font-size: 12px;"><div style="margin: 0px;">(lldb) b A::~A()</div><div style="margin: 0px;">Breakpoint 3: no locations (pending).</div><div style="margin: 0px;">WARNING: Unable to resolve breakpoint to any actual locations.</div><div><div style="margin: 0px;">(lldb) b A::getVal()</div><div style="margin: 0px;">Breakpoint 1: where = MipsLinkage`A::getVal() + 12 at MipsLinkage.cpp:6, address = 0x0000000100000e1c</div><div style="margin: 0px;">(lldb) b FunctionLocal::foo</div><div style="margin: 0px;">Breakpoint 9: no locations (pending).</div><div style="margin: 0px;">WARNING: Unable to resolve breakpoint to any actual locations.</div><div style="margin: 0px;">(lldb) b foo</div><div style="margin: 0px;">Breakpoint 10: where = MipsLinkage`foo + 16 at MipsLinkage.cpp:11, address = 0x0000000100000dd0</div></div><div style="margin: 0px;"><div style="margin: 0px;"><br></div></div></div><div style="margin: 0px; font-size: 12px;">-- adrian</div><div style="margin: 0px;"><br></div></div></div><div></div></body></html>