Thanks, I will be waiting for it.<div><br></div><div> Filipe<br><br><div class="gmail_quote">On Fri, Jul 29, 2011 at 12:11, Greg Clayton <span dir="ltr"><<a href="mailto:gclayton@apple.com">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;">Sean Callanan has a patch that is coming that improves C++ expressions. We know of this issue and are currently working to resolve it. The fix should be landing in the next day or so.<br>
<br>
Greg Clayton<br>
<div><div></div><div class="h5"><br>
On Jul 28, 2011, at 6:47 PM, Filipe Cabecinhas wrote:<br>
<br>
> Hi all,<br>
><br>
> I'm trying to debug lldb to see where the active thread gets unselected, using my patch for the "frame return" command.<br>
><br>
> But I'm having some problems. Most of the time, I can't evaluate C++ expressions, like "m_threads[idx]" (missing symbol: …), or "process->GetSelectedThread()" (call is ambiguous, but no candidates are given).<br>
> Since I was having these errors, I tried checking out if I could find those candidates while clang parsed the AST.<br>
><br>
> Right now, I'm running a test program in lldb in lldb in lldb… It's not that fun :-)<br>
><br>
> I will stop the bottom debugger in CommandObjectThread.cpp:413 and, in the middle lldb, run the command:<br>
> frame #0: 0x000000010031d875 LLDB`CommandObjectThreadStepWithTypeAndScope::Execute(lldb_private::Args&, lldb_private::CommandReturnObject&) + 197 at CommandObjectThread.cpp:413<br>
> 410 else<br>
> 411 {<br>
> 412 const uint32_t num_threads = process->GetThreadList().GetSize();<br>
> -> 413 Thread *thread = NULL;<br>
> 414<br>
> 415 if (command.GetArgumentCount() == 0)<br>
> 416 {<br>
> 1) expr process->GetThreadList()<br>
><br>
><br>
> This command, normally, will error out with:<br>
> error: call to member function 'GetThreadList' is ambiguous<br>
> note: candidate function<br>
> note: candidate function<br>
> error: 1 errors parsing expression<br>
><br>
> Not listing the candidate functions (as it should?). If I stop that lldb, I can't check the Diagnostic object (with the outermost lldb):<br>
> frame #0: 0x000000010042b182 LLDB`clang::CompilerInstance::getDiagnostics() const + 114 at CompilerInstance.h:254<br>
> 251 /// Get the current diagnostics engine.<br>
> 252 Diagnostic &getDiagnostics() const {<br>
> 253 assert(Diagnostics && "Compiler instance has no diagnostics!");<br>
> -> 254 return *Diagnostics;<br>
> 255 }<br>
> 256<br>
> 257 /// setDiagnostics - Replace the current diagnostics engine.<br>
> 0) expr *(Diagnostics.Obj)<br>
> Assertion failed: (D && "Cannot get layout of forward declarations!"), function getASTRecordLayout, file RecordLayoutBuilder.cpp, line 1835.<br>
> [1] 73430 illegal hardware instruction lldb<br>
><br>
> This triggers an assert and shuts down clang. I have built lldb with the debug version of llvm+clang, as it says on the docs/ folder.<br>
><br>
> Shouldn't clang+lldb be able to get that information? Any clues on where the bug might lie? (clang? lldb?)<br>
><br>
> Regards,nbsp; Filipe Cabecinhas<br>
><br>
> P.S: XCode blows up, too, which shouldn't happen.<br>
</div></div>> _______________________________________________<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>
<br>
</blockquote></div><br></div>