[lldb-dev] Blog posting about my experience with LLDB so far
bruce.mitchener at gmail.com
Fri Jun 27 17:54:58 PDT 2014
On Sat, Jun 28, 2014 at 12:02 AM, Greg Clayton <gclayton at apple.com> wrote:
> 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.
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
> - The single character typename things is fixed in Beta 6
> - 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?
> - 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.
> - synthetic children not being shown for all pointer types should be easy
> to fix
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.
> Your comment:
> "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."
> 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?
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. :)
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev