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

[Adrian Prantl]

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.
(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.
(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

-- adrian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140217/5c0ed2a5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: MipsLinkage.cpp
Type: application/octet-stream
Size: 355 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140217/5c0ed2a5/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140217/5c0ed2a5/attachment-0001.html>