<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jun 28, 2014 at 12:02 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">I am glad you have been able to make things work and the LLDB will be happy to help you fix the issues you have run into.</blockquote>
<div><br></div><div>I had a great time doing this work and have learned a lot so far about LLDB. :)  I'm looking forward to helping fix some of the issues. (As you probably saw, I requested SVN access to be able to commit patches after approval.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- The single character typename things is fixed in Beta 6<br>
- The variable depth issue should be easy to fix, we haven't had any targets that represent types as instances, so displaying infinite values hasn't been a problem because we stop at pointer boundaries. It might be better to teach LLDB that certain data types should be treated as pointers and not recursively expanded to fix this?<br>

- debug info missing issue: there is a compiler option that help more complete debug info for clang: -fstandalone-debug. Try enabling this option and see if this improves things.<br>
- synthetic children not being shown for all pointer types should be easy to fix<br></blockquote><div><br></div><div>Thanks. I've been looking into the variable depth issue and figured that I would start a new thread for that. I've largely worked out the debug info issues, but I'll look into -fstandalone-debug.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Your comment:<br>
<br>
"Don't rely on running code within the target process. By not running code within the target process, we can also support debugging core files. This means that we need to implement things in terms of reading memory from the target process."<br>

<br>
We already have this. The expression parser knows how to emulate IR for expressions if the expression results in only reading/writing memory or registers. Emulating the IR doesn't handle function calls as emulating the ABI for all arguments correctly is a very tricky issues and one that we leave the compiler to do by using the JIT. Is there something more you were looking to accomplish here?<br>
</blockquote><div><br></div><div>Our previous debugging "solution" involved calling some C functions in the language run-time. This was a mess for various reasons and I didn't use it much under lldb. Under gdb, we ran into issues where the debug functions would crash occasionally and things would be in a worse state. :)</div>
<div><br></div><div>So a goal for my work  here was to re-implement the C functions on the debugger side in Python to avoid all of the issues we'd had in the past.</div><div><br></div><div> - Bruce</div><div><br></div>
</div></div></div>