<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 11:03 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 style="word-wrap:break-word"><div><div class="h5"><br><div><div>On Feb 17, 2014, at 10:26, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:</div>
<br><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><div><br>
On Feb 15, 2014, at 17:25, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>> wrote:<br>
<br>
> On Sat, Feb 15, 2014 at 2:57 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">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>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></div><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></blockquote><div><br></div><div>I do wonder what happens if there are multiple As. Is LLDB nice enough to describe the set of candidates?<br>
<br>If LLDB happily accepts partially and unqualified names, you guys might gain some debug info size by disabling imported_modules and imported_declarations - they wouldn't serve any purpose to your debugger. (though I'm not sure how big they are - there might be no real space savings there)<br>
<br>Explains why no one complained that they were missing, though... :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">
<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></div></div></blockquote><div><br>Adrian - I'm assuming "A" is just a class at global scope? (not in a namespace or function, etc)<br><br>So this is consistent with Greg's description that the simple name (since that's the DW_AT_name on the member subprogram) works, but qualified names don't without the mangled name. </div>
<div><br></div><div>LLDB doesn't form the qualified name from the scopes in which the DIE appears. GCC does. I don't know what this space/perf tradeoff looks like.<br><br>Even if this is a matter for accelerator tables, that doesn't necessarily mean the mangled name should also be in the DIE, though - right? It could just appear in the accelerator table.<br>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div style="margin:0px;font-size:14px;font-family:Menlo"><div style="margin:0px">
<div style="margin:0px;font-size:12px"><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></div></div></div></blockquote><div><br>foo is a member function of a class inside FunctionLocal? Or is it the implicit ctor? If it's the latter then this example overlaps with the first one. Perhaps try the getVal example except with a nested class instead of a global one. </div>
</div></div></div>