[Lldb-commits] [PATCH] Patch for LLDB demangler for demangling upon actual language

[Zachary Turner]

Wasn't aware of those limitations with itanium mangled.  I think you could
come up with a useful set of common functionality though, especially if you
just look at how we're currently inspecting mangled names and build the
interface around the operations we're already doing.

As for increasing the size by 1 pointer, I think it would actually reduce
the size by 1 pointer.  As discussed earlier, there's no advantage to
storing both the mangled and demangled name in Mangled, because ConstString
already has this.  So you could just store m_mangled directly in the
Symbol.   Calculate the language from the string, create the appropriate
mangler, then call Demangle on it and use it (without storing it the
result).

Can you answer the question "is this name mangled" just by inspecting the
string?  If the answer is yes, we don't even need the is_mangled flag and
that solves that problem too.

On Fri Jan 30 2015 at 4:32:20 PM Greg Clayton <clayborg at gmail.com> wrote:

> I am all for a powerful class that can pull apart mangled names and tell
> you about them. The power in the mangled names vary quite a bit so you
> can't rely on this. For example, in itanium mangling you detangle to
> "foo::bar::baz(int, float)", you have no idea if this is "namespace foo" or
> "class foo" or "struct foo", same goes for "bar" and you don't know if
> "baz" is a function or a method or a static class method. So Itanium
> mangling isn't great. There are languages that do mangle things very well
> and there is a wealth of knowledge to be extracted from it, so I agree we
> need a class to do it. If you want to go virtual, you will need to come up
> with another class other than Mangled because making it virtual increases
> the instance size by 1 pointer.
>
> Greg
>
> > On Jan 30, 2015, at 4:26 PM, Zachary Turner <zturner at google.com> wrote:
> >
> >
> >
> > On Fri Jan 30 2015 at 4:03:59 PM Greg Clayton <clayborg at gmail.com>
> wrote:
> >
> > > On Jan 30, 2015, at 3:50 PM, Zachary Turner <zturner at google.com>
> wrote:
> > >
> > > I agree that if memory is important then we should use the opportunity
> to reduce memory usage rather than keeping it the same by changing stuff.
> But the reason I asked leads into my next question.
> > >
> > > I've been thinking about mangling and demangling for a while and how
> it relates to Windows.  I see a lot of code all over the place that
> manually inspects mangled names, and usually the code is all custom and
> handrolled.  (If you're interested I can point you to a bunch of
> examples).  I don't like this way of doing things and I think it's
> generally fragile.  There should be one place that's responsible for
> anything to do with mangling.  All these places that are inspecting strings
> for _Z or ? should just be calling some class to ask it about the
> properties of this string.
> >
> > Exactly, why can't we just look at the mangled name and look for the
> prefix and return the language we calculate?
> >
> > > The most sensible place to do that, to me, seems like the ABI.  So I'm
> imagining that there's a Mangler base class, and then from that there is an
> ItaniumCppMangler, a MsCppMangler, and let's say perhaps a JavaMangler for
> the purposes of this CL.  Maybe they share some code, but that's not the
> important part.
> >
> > Doesn't windows actually have 2 forms of mangling? Itanium + the $
> mangling?
> > Yes but the mangling scheme is still tied to the ABI.  When Itanium
> mangling is used, it's because you compiled with GCC or some other non
> Microsoft compiler.  When MS ABI is used, it's because you compiled with
> cl.exe or clang-cl.  So with the difference in mangling, you also get all
> the other differences that come with an ABI change.
> >
> >
> > >
> > > ABI provides a method called getMangler().  It returns a singleton
> instance (which for Windows would be an MsCppMangler, and for everyone else
> would be an ItaiumCppMangler).
> >
> > Again, why do we need to get so fancy. I would prefer to avoid this if
> we can just try demangling if it starts with one of the mangling prefixes.
> > Well, if you start with the notion that a Mangling abstraction for
> different ABIs and languages is useful, then this really isn't that much
> additional complicatation.  Say someone wanted to add support for debugging
> Java, or Haskell, or whatever language.  In order to fully integrate, they
> would need to fixup every location in the code that deals with mangled
> names.  The expression evaluator is a good example.  If you could just
> create a mangler instance with the appropriate properties, then everything
> just works.
> >
> > I'm actually not totally against your idea of calculating the language
> from the mangled string.  Maybe it will have limitations in the future, but
> it's probably fine now.  What I think is a useful is, after you know the
> language and ABI, being able to have a single interface which you can ask
> questions to.  IsVariable(), IsFunction(), IsGuardVariable(), Demangle(),
> that kind of thing.  And there's enough useful functionality here that I
> think it's best exposed through a virtual interface with concrete
> implementations for each scheme.
> >
> > For C++, this could be tied to the ABI class.  Some other way might be
> useful too, the ABI just seems logical to me.  Just some way to go from
> triple -> mangler though.  For other languages I can think of, the language
> itself defines the ABI, so you wouldn't need this separation.  There could
> just a single JavaMangler, for example.
> >
> > You could still have a single function that analyzes a mangled string to
> calculate a language and return an appropriate Mangler instance though, I
> agree that seems like a fine approach.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20150131/bbfc515f/attachment.html>