<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 17, 2014 at 10:02 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5"><br>
On Feb 15, 2014, at 2:57 PM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>
<br>
> So when comparing Clang's debug info strings to GCC's I came across a couple of disparities hinging on the inclusion of linkage names on certain functions. Here are a few differences:<br>
><br>
> * Clang includes linkage names on file-local (static or anon namespace) functions. GCC does not.<br>
> * Clang does not include the linkage name of member functions of function-local classes. GCC does, if the function is non-static/non-anonymous namespace and inline (ie: the member function has linkonce-odr linkage, not internal linkage)<br>

> * Clang does not include the linkage name for constructors and destructors - this may be necessary due to the difference (GCC duplicates, Clang has one version call the other) in implementations, but I doubt it. I assume we still emit multiple member functions, one to describe each version of the ctor/dtor we're emitting.<br>

><br>
> It looks like at least for the first case, this may've been deliberate ( <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 doesn't explain why and points to rdar://11079003 which Jim Grosbach told didn't have a great deal more context) but I don't have enough context to understand why and whether it's just a GCC bug that they don't emit it, or something tools should handle better, etc.<br>

><br>
> So - any thoughts on the disparity and if/why it's necessary?<br>
<br>
</div></div>It is necessary if you want your debugger to be able to evaluate an expression that fully qualifies the name of the static:<br>
<br>
(lldb) expr a::b::g_foo<br>
<br>
If you don't have the mangled name, you can only do:<br>
<br>
(lldb) expr g_foo<br></blockquote><div><br></div><div>A cursory experiment with GDB doesn't seem to exhibit this behavior. Have I correctly captured the nature of your example here:<br><br>







<p class="">$ cat mang.cpp<br>namespace x {<br>static void func() {}<br>}<br><br>int main() { x::func(); }<br>$ g++-4.8.1 mang.cpp -g<br>$ gdb a.out<br>(gdb) start<br>Temporary breakpoint 1 at 0x40055a: file mang.cpp, line 5.<br>
Starting program: /tmp/dbginfo/a.out <br><br>Temporary breakpoint 1, main () at mang.cpp:5<br>5       int main() { x::func(); }<br>(gdb) p x::func()<br>$1 = void<br>(gdb) exit <br>$ llvm-dwarfdump a.out | grep linkage_name<br>
$<br><br>No mention of any linkage names yet the debugger appears to have been able to identify the fully qualified name and call the function.</p></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Then you might get many many many different versions if more than one file contains a static named "g_foo".<br></blockquote><div><br>I'm not quite sure what you're saying here - this is true of any static, even those in namespaces - there may be (will be) multiple across a project all meaning different things. The mangled name won't be unique to any particular one.<br>
 </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Also, users never tend to fully qualify names and might try to execute:<br>

<br>
(lldb) expr b::g_foo<br></blockquote><div><br></div><div>From within namespace 'a' or just as a partial identifier that the user expects the debugger to search for? I'm not sure if GDB offers this functionality (I realize you're talking about LLDB, but I don't have it setup to experiment with) so I can't compare, but I don't see any reason GDB wouldn't be able to implement that without the mangled name too.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">expecting to see "a::b::g_foo". LLDB is able to find these variables by first looking for all the variable base names that match "g_foo", then removing any whose demangled named doesn't contain "b::g_foo".<br>

<br>
So the mangled names on statics allows debuggers to do the right thing and be able to correctly display qualified static variables and is very important for good debugging.</blockquote><div><br>GDB /seems/ to be getting away without it and providing similar functionality (I could be wrong - perhaps my examples aren't what you had in mind).<br>
<br>Is it just that it's a performance optimization compared to having to walk the DIE parent chain to build a fully qualified name? If that's the case, can we quantify that perf/size tradeoff? (though at that point it's a fair question about why have the mangled name at all - I'm not really sure what GDB uses it for when it is present (on externally visible functions))<br>
<br>- Dave </div></div></div></div>