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

[Zachary Turner]

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/1a101ae1/attachment.html>