<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Alex,<div><br></div><div>the expression parser works roughly as follows (in the case of JIT execution, anyway):</div><div><br></div><div>- you type in some code;</div><div>- we wrap it up so that it looks like a translation unit to Clang (i.e., no bare code);</div><div>- we send it to Clang to produce an IR module, and Clang asks the ClangExpressionDeclMap/ClangASTSource for all the variables and types in the program;</div><div>- we prepare that IR module for execution with IRForTarget; and</div><div>- the JIT produces binary code which we can run.</div><div><br></div><div>The IR module that the Clang parser produces already contains all of the external function references like _ZNKSbIcSt17char_traits<char>St15allocator<char>E5c_strEv. LLDB is not responsible for generating these; that is Clang’s job.</div><div><br></div><div>One immediate problem I see with this symbol is that it is a mangled name with angle brackets (<>) in it. I don’t believe this is proper mangling.</div><div><br></div><div>What I think is happening here is that the debug information is telling you that the type of something is char_traits<char> but treating that as a normal type instead of a templated type. Then we’ll report a normal type with a name containing angle brackets to Clang, and it’ll produce bogus mangled names as you see.</div><div><br></div><div>One way you can see what types are being reported for things is by enabling the expression log:</div><div><br></div><div>(lldb) log enable -f /tmp/lldb.expr.log.txt lldb expr</div><div>(lldb) expr <i>your expression</i></div><div><i><br></i></div><div>That should tell you what types we reported (and what IR we got). You’ll want to be very familiar with this log to fix bugs in the expression parser.</div><div><br></div><div>Good luck and let me know if you have any more questions.</div><div><br><div>
<div>Sean</div>
</div>
<br><div><blockquote type="cite"><div>On Jun 30, 2014, at 9:44 AM, Alex Pepper <<a href="mailto:apepper@blueshiftinc.com">apepper@blueshiftinc.com</a>> wrote:</div><br class="Apple-interchange-newline"><div>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>- Alex<br>_______________________________________________<br>lldb-dev mailing list<br><a href="mailto:lldb-dev@cs.uiuc.edu">lldb-dev@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev<br></div></blockquote></div><br></div></body></html>