[lldb-dev] LLDB Expression Parser Name Mangling

[Zachary Turner]

Questions from a random observer: Why are these two manglings of
std::string hardcoded into the code?  Or better yet, why is std::string
even special cased to begin with?  Is the debug visualization support not
sufficient to be able to deal with stl strings in a useful manner?


On Mon, Jun 30, 2014 at 11:44 AM, Greg Clayton <gclayton at apple.com> wrote:

>
> > On Jun 30, 2014, at 10:52 AM, Alex Pepper <apepper at blueshiftinc.com>
> wrote:
> >
> > * I sent this earlier before I registered, sorry in advance if this
> shows up as a duplicate.
> >
> > I have been familiarizing myself with the expression parsing code in
> LLDB with the intention of finding and fixing several expression parser
> related bugs.
> >
> > The first issue that I have been investigating in detail is related to
> calling c_str() on a standard string.  The expression fails because LLDB is
> not able to match up the mangled function name with any names in the symbol
> table.  There is special handling for standard strings in
> IRForTarget::GetFunctionAddress to support two variants of the mangled name
> prefix of, _ZNKSbIc and _ZNKSs.  The _ZNKSbIc represents basic_string<char>
> whereas _ZNKSs represents string which is a typedef of basic_string<char>.
> In this case the full name in the g++ compiled dwarf symbols is
> _ZNKSs5c_strEv,  Clang also generates the same symbol.  The call to
> m_decl_map->GetFunctionAddress is failing because the mangled name that is
> being generated by the JIT compiled expression is actually the fully
> specified name, _ZNKSbIcSt17char_traits<char>St15allocator<char>E5c_strEv,
> which is equivalent to basic_string<char,char_traits<char>,allocator<char>>.
> > I have been walking through the expression parsing code but have not
> been able to locate where this name is actually generated.  I am guessing
> the name is generated during the ParseAST but I have not been able to track
> it down yet, any help would be appreciated.
>
> The compiler will generate this in the debug info. When we go looking for
> a symbol or function, the compiler will ask us where the function is, and
> we usually find this in the C++ standard library shared library. So you
> should do a:
>
> (lldb) image dump symtab
>
> This should dump all symbols from all shared libraries and look for
> std::basic_string somewhere in the mix and see what symbols. You
> _ZNKSbIcSt17char_traits<char>St15allocator<char>E5c_strEv detangles to:
>
> std::basic_string<char, std::char_traits<char>, std::allocator<char>
> >::c_str() const
>
> on our system. I would check the symbols in your libstdc++ shared library
> and see what symbols are there for basic_string and see why things aren't
> matching up.
>
> Greg
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140630/d830e226/attachment.html>