<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jul 28, 2014 at 5:08 PM, 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
> On Jul 28, 2014, at 2:26 PM, Alex Pepper <<a href="mailto:apepper@blueshiftinc.com">apepper@blueshiftinc.com</a>> wrote:<br>
><br>
> I investigated bug 15302, which is described as:<br>
><br>
> "LLDB does not print 'anonymous namespace' prefix for variable names (if inferior built with GCC on Linux)"<br>
><br>
> What I found was that the GCC dwarf data does not contain a mangled name for a variable defined in an anonymous namespace, unlike clang.  LLDB VariableObject depends on the mangled name to identify the anonymous namespace for a variable, so in the test case it does no print the (anonymous namespace) prefix.  I checked the dwarf data using dwarfdump and nm.  In the case of dwarfdump the variable is a child of the anonymous namespace but there is no mangled name, but when I use nm to dump the symbols it displays the mangled name.  I am not sure if this means nm is generating the name or getting the symbol from somewhere else.<br>

<br>
</div>nm only looks at the symbol table and the symbol table will contain only the mangled name for the variable.</blockquote><div><br></div><div>Yeah, I would try to solve this by looking at .symtab, which is where nm gets the mangled name.  I doubt gcc will start emitting linkage names into dwarf soon enough to be useful.  The dwarf linkage name might also be missing due to -gline-tables-only / -gmlt type flags.</div>
</div></div></div>