[cfe-dev] Where do we really need mangled names

[Adrian Prantl]

On Feb 17, 2014, at 12:15, David Blaikie <dblaikie at gmail.com> wrote:

> 
> 
> 
> On Mon, Feb 17, 2014 at 11:03 AM, Adrian Prantl <aprantl at apple.com> wrote:
> 
> On Feb 17, 2014, at 10:26, David Blaikie <dblaikie at gmail.com> wrote:
> 
>> 
>> 
>> 
>> On Mon, Feb 17, 2014 at 10:16 AM, Adrian Prantl <aprantl at apple.com> wrote:
>> 
>> On Feb 15, 2014, at 17:25, Eric Christopher <echristo at gmail.com> wrote:
>> 
>> > On Sat, Feb 15, 2014 at 2:57 PM, David Blaikie <dblaikie at gmail.com> wrote:
>> >> 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:
>> >>
>> >> * Clang includes linkage names on file-local (static or anon namespace)
>> >> functions. GCC does not.
>> >> * 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)
>> >> * 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.
>> >>
>> >> It looks like at least for the first case, this may've been deliberate (
>> >> http://llvm.org/viewvc/llvm-project?view=revision&revision=154570 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.
>> >>
>> >> So - any thoughts on the disparity and if/why it's necessary?
>> >>
>> >
>> > My thought is that it is basically there to assist in lookup of
>> > symbols. I put the earlier patch in because it was seen as useful
>> > there. In general I find that mangled names are helpful on any entity
>> > that we might want to put into a lookup table since we might have a
>> > qualified name that we'd like to look up. I doubt that any
>> > discrepancies here are intentional, but that any time we have a
>> > mangled name we probably want to add it.
>> 
>> 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.
>> 
>> 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))?
>> 
>> It'd be nice to get these things consistent.
> 
> What exactly would you like me to test?
> 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:
> 
> (lldb) b A
> Breakpoint 8: 2 locations.
> 
> I do wonder what happens if there are multiple As. Is LLDB nice enough to describe the set of candidates?
> 
> 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)
> 
> Explains why no one complained that they were missing, though... :)
>  
> (lldb) b ~A
> Breakpoint 7: 2 locations.
> (lldb) b A::A
> Breakpoint 6: no locations (pending).
> WARNING:  Unable to resolve breakpoint to any actual locations.
> (lldb) b A::~A()
> Breakpoint 3: no locations (pending).
> WARNING:  Unable to resolve breakpoint to any actual locations.
> 
> Adrian - I'm assuming "A" is just a class at global scope? (not in a namespace or function, etc)
> 
> 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. 
> 
> 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.
> 
> 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.
>  
> (lldb) b A::getVal()
> Breakpoint 1: where = MipsLinkage`A::getVal() + 12 at MipsLinkage.cpp:6, address = 0x0000000100000e1c
> (lldb) b FunctionLocal::foo
> Breakpoint 9: no locations (pending).
> WARNING:  Unable to resolve breakpoint to any actual locations.
> (lldb) b foo
> Breakpoint 10: where = MipsLinkage`foo + 16 at MipsLinkage.cpp:11, address = 0x0000000100000dd0
> 
> 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. 

the source file was attached to my previous message :-)

-- adrian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140217/baaf70fb/attachment.html>