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

[Zachary Turner]

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.

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.

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

In the Symbol class, then, all you need to store is the mangled name.  Implement a method in Symbol called getMangler() which looks at m_comp_unit, and either gets the ABI and calls getCppMangler (if Lang is C++) or a null mangler (if Lang is C)  or a java mangler (if Lang is Java), etc.

Then, just call the method on it.

All this seems complicated, but the advantage is that now this logic is abstracted for anyone else who wants to use it.  The Mangler interface could provide such methods as IsGuardVariable() or IsFunction() that things like the interpreter could use by getting the correct mangler from the ABI, for example.  And all of the places in the code that currently have hardcoded mangler checks could be made to work in the presence of ABI differences and language differences easily.

And this doesn't impose any memory penalty on Symbol (and actually reduces the footprint of each Symbol by the size of 1 pointer)


REPOSITORY
  rL LLVM

http://reviews.llvm.org/D7302

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/