Hello all,
Earlier this week, I took the time to summarize my experience so far with integrating Dylan support with LLDB:
http://dylanfoundry.org/2014/06/25/integrating-with-lldb/
I have a lot of work left that I’d like to do, so there will be future installments. In the short term, I have a lot of loose ends to tie up.
I hope this is useful information for someone. I’m hoping to help fix some of these issues myself and am looking at various possible fixes and will start some new threads.
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.
- 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
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?
Greg
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
approval.)
- 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.
- Bruce