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

[David Blaikie]

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=154570which
>> >> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140217/dc105716/attachment.html>