<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 rdar://11079003 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><br>- David </div></div></div></div>