> I would prefer to see this patch done differently. There are new methods make > on Mangled and on ConstString that probably don't need to be there.
New methods on ConstString are required in order to undo/redo the demangling once the language is known. > Can we have the mangled names be correct from the start by specifying the > language when we create the Mangled string in the first place? No, because the first time the symbol is demangled, we find the linker/minimal symbol and the language is unknown since there is no debug info yet. Then we parse the debug info and find the language in the CU, but the demangling has already taken place so we must undo what we did in the correct language. > We don't want to store a language with the Mangled object because that would > make lldb_private::Symbol take up even more space since it has a Mangled > object inside of it and lldb_private::Symbol objects are the biggest memory > hogs in LLDB right now (we did memory profiling a while back). I know. Hence this patch avoids the extra members. > So I would prefer to see a solution that allows clients to specify the > language when setting the mangled name. If this mangled name is > eLanguageTypePascal83 or eLanguageTypeJava, then demangle right away and fix > up the mangled string before it gets entered as the demangled counterpart. That is simply not possible. The language is not known until the debug info is read. For an exe that has mixed languages (e.g. C++ and Pascal) using Itanium mangling, only the debug info can tell us what the correct language is, and we don't get that information until the DWARF is parsed. REPOSITORY rL LLVM http://reviews.llvm.org/D10744 EMAIL PREFERENCES http://reviews.llvm.org/settings/panel/emailpreferences/ _______________________________________________ lldb-commits mailing list lldb-commits@cs.uiuc.edu http://lists.cs.uiuc.edu/mailman/listinfo/lldb-commits
