[lldb-dev] problems with dynamic values

Greg Clayton gclayton at apple.com
Tue Mar 24 15:37:03 PDT 2015

So question: is the "go" compiler part actually part of clang? What you should do really depends on what your answer to this is.

> On Mar 24, 2015, at 3:05 PM, Ryan Brown <ribrdb at google.com> wrote:
> I'm trying to support printing go interfaces. 
> After reading through the list archives, it seems like the way to do this is add my Go type information to ClangASTType and implement a GoLanguageRuntime.
> So I added a "int m_go_kind" field to ClangASTType and set it in SymbolFileDWARF. However I'm having a couple issues:
> 1) It seems like some places create new ClangASTTypes directly instead of using the ones from the DWARF info. So if I use 'frame variable' I see the dynamic type, but if I do 'print g' the go type info gets lost.
> 2) The dynamic values always seem to print as invalid, even though it seems like I'm returning the right thing from GetDynamicTypeAndAddress. For example:
> (lldb) frame variable
> (main.square) g = (width = <parent has invalid value.>, height = <parent has invalid value.>)
> But if I step through the code after GetDynamicTypeAndAddress returns, it looks like it's successfully reading the data. I can print the actual value from python:
> >>> g = lldb.frame.EvaluateExpression("g")
> >>> print g
> (main.geometry) $1 = {
>   tab = 0x00007ffff7fcf6f0
>   data = 0x000000c20800a210
> }
> >>> d = g.GetChildAtIndex(1)
> >>> print d.Cast(t.GetPointerType()).Dereference()
> (main.square) *data = (width = 3, height = 4)
> And these addresses are the same ones my C++ code is returning, so I don't know what's wrong.
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev

More information about the lldb-dev mailing list