<div dir="ltr">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?</div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jun 30, 2014 at 11:44 AM, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com" target="_blank">gclayton@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
> On Jun 30, 2014, at 10:52 AM, Alex Pepper <<a href="mailto:apepper@blueshiftinc.com">apepper@blueshiftinc.com</a>> wrote:<br>
><br>
> * I sent this earlier before I registered, sorry in advance if this shows up as a duplicate.<br>
><br>
> I have been familiarizing myself with the expression parsing code in LLDB with the intention of finding and fixing several expression parser related bugs.<br>
><br>
> 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>>.<br>

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

<br>
</div></div>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:<br>

<br>
(lldb) image dump symtab<br>
<br>
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:<br>

<br>
std::basic_string<char, std::char_traits<char>, std::allocator<char> >::c_str() const<br>
<br>
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.<br>
<span class="HOEnZb"><font color="#888888"><br>
Greg<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
</div></div></blockquote></div><br></div>