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 <rib...@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@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
