Best way to inspect the parse tree from Sparse

Best way to inspect the parse tree from Sparse

[Dibyendu Majumdar]

Hi,

I would like to understand the structure of the parse tree generated
by Sparse a bit better. I am looking at the output from the show_*()
functions but it is not clear to me exactly what the output means. For
example:

extern int printf(const char *, ...);

int main(int argc, const char *argv[]) {
printf("hello world!\n");
return 0;
}

Results in:

.align 4
int extern [signed] [addressable] [toplevel] main( ... )
        movi.64         v2,&"hello world!\n"
        push.64         v2
        call            printf
        add.64          vSP,vSP,$8
        mov.32          v3,retval
        movi.32         v4,$0
        addi.64         v5,vFP,$offsetof(return:00000202755B1A98)
        st.32           v4,[v5]
        ret             (00000202755B1A98)
.L00000202755B1A98:
        addi.64         v6,vFP,$offsetof(return:00000202755B1A98)
        ld.32           v7,[v6]
        mov.32          retval,7
        ret


I get the first four lines, but the rest don't make sense to me. I
suppose that the dump is trying to show the parse tree in a linear
form ...  but is that useful? Would it be better to dump the parse
tree in a different form?

Regards
Dibyendu

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

On Mon, Aug 7, 2017 at 11:11 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi,
>
> I would like to understand the structure of the parse tree generated
> by Sparse a bit better. I am looking at the output from the show_*()
> functions but it is not clear to me exactly what the output means. For
> example:

You can try test-inspect, it will pop up a gtk window which
you can click on the object and expand the object members.

It is not complete but it is very easy to extend.

Chris

Re: Best way to inspect the parse tree from Sparse

[Luc Van Oostenryck]

On Mon, Aug 07, 2017 at 04:11:43PM +0100, Dibyendu Majumdar wrote:
> Hi,
> 
> I would like to understand the structure of the parse tree generated
> by Sparse a bit better. I am looking at the output from the show_*()
> functions but it is not clear to me exactly what the output means. For
> example:
> 
> extern int printf(const char *, ...);
> 
> int main(int argc, const char *argv[]) {
> printf("hello world!\n");
> return 0;
> }
> 
> Results in:
> 
> .align 4
> int extern [signed] [addressable] [toplevel] main( ... )
>         movi.64         v2,&"hello world!\n"
>         push.64         v2
>         call            printf
>         add.64          vSP,vSP,$8
>         mov.32          v3,retval
>         movi.32         v4,$0
>         addi.64         v5,vFP,$offsetof(return:00000202755B1A98)
>         st.32           v4,[v5]
>         ret             (00000202755B1A98)
> .L00000202755B1A98:
>         addi.64         v6,vFP,$offsetof(return:00000202755B1A98)
>         ld.32           v7,[v6]
>         mov.32          retval,7
>         ret
> 
> 
> I get the first four lines, but the rest don't make sense to me.

The 'vFP' is the (virtual) Frame Pointer and the $offsetof() is
the offset to where the variable is stored in the frame.
'retval' seems to be a pseudo-register used for the return value
of function calls and 'return' seems to be a pseudo-variable holding
the return value.

So v3 hold the return value of the printf() (and is ignored) then
0 is stored in the 'return' pseudo-variable and is read-back just
after to be returned by the function.


> I suppose that the dump is trying to show the parse tree in a linear
> form ...  but is that useful? Would it be better to dump the parse
> tree in a different form?

Yes, I think so too.
I only tried it a few time and it wasn't at all helping me.
The parsing tree is all about the statements and the expressions,
so I always end to look directly at the code.
I dunno about the inspect & dissect tools.

-- Luc

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

On Mon, Aug 7, 2017 at 2:46 PM, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> I only tried it a few time and it wasn't at all helping me.
> The parsing tree is all about the statements and the expressions,
> so I always end to look directly at the code.
> I dunno about the inspect & dissect tools.

The test-inspect knows about statements and expressions. You
just need to expand the right object.

Chris

Re: Best way to inspect the parse tree from Sparse

[Dibyendu Majumdar]

Hi Chris,

On 8 August 2017 at 00:35, Christopher Li <sparse@chrisli.org> wrote:
>
> The test-inspect knows about statements and expressions. You
> just need to expand the right object.
>

Thanks - I will try to build this. Previously I tried using the
test-inspect that comes with Ubuntu and unfortunately it crashes /
doesn't work properly. Perhaps if I build the latest version it will
be more stable.

Will let you know.

Regards
Dibyendu

Re: Best way to inspect the parse tree from Sparse

[Dibyendu Majumdar]

Hi Chris,

On 9 August 2017 at 18:14, Dibyendu Majumdar <mobile@majumdar.org.uk> wrote:
> On 8 August 2017 at 00:35, Christopher Li <sparse@chrisli.org> wrote:
>>
>> The test-inspect knows about statements and expressions. You
>> just need to expand the right object.
>>
>
> Thanks - I will try to build this. Previously I tried using the
> test-inspect that comes with Ubuntu and unfortunately it crashes /
> doesn't work properly. Perhaps if I build the latest version it will
> be more stable.
>
> Will let you know.
>

I built the latest version (master branch) - and tried to run it. It
immediately crashes with core dump as soon as I click on anything.

Regards
Dibyendu

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

On Wed, Aug 9, 2017 at 1:42 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> I built the latest version (master branch) - and tried to run it. It
> immediately crashes with core dump as soon as I click on anything.

Hmm, works for me on Fedora 26.

Do you have gtk2-devel installed? In Ubuntu it should be libgtk2.0-dev.
Did you give it a C file to parse. e.g. ./test-inspect parse.c

You can also do a gdb on the test-inspect and report back what
back trace do you get. My wild guess is that, it is got some incomparable
library or some thing.

Too bad it is not working for you, otherwise it should be the better one
that show the AST tree nodes.

Chris

Re: Best way to inspect the parse tree from Sparse

[Dibyendu Majumdar]

Hi Chris,

Yes I do have libgtk-2.0-dev installed as otherwise it would not build.

On 9 August 2017 at 19:41, Christopher Li <sparse@chrisli.org> wrote:
> You can also do a gdb on the test-inspect and report back what
> back trace do you get. My wild guess is that, it is got some incomparable
> library or some thing.
>

Here is the back trace from gdb:

Starting program: /home/dylan/github/linux-sparse/test-inspect parse.c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffede40700 (LWP 19249)]
[New Thread 0x7fffed63f700 (LWP 19250)]
[New Thread 0x7fffece3e700 (LWP 19251)]

Thread 1 "test-inspect" received signal SIGSEGV, Segmentation fault.
ast_iter_n_children (tree_model=0x725400, iter=0x0) at ast-model.c:404
404        AstNode  *node = iter->user_data;

Regards
Dibyendu

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

On Wed, Aug 9, 2017 at 2:47 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
>
> Thread 1 "test-inspect" received signal SIGSEGV, Segmentation fault.
> ast_iter_n_children (tree_model=0x725400, iter=0x0) at ast-model.c:404

Err, iter == NULL.

The function comment said it all. if iter == NULL, should return the
root node's children number.

Can you try the following one line change?
I can only verify it compiles. But I have no way to test it.

I also totally forget how this tree view model works now.
Let's hope that fix it.

Thanks

Chris

diff --git a/ast-model.c b/ast-model.c
index 704c487..cbfdc1f 100644
--- a/ast-model.c
+++ b/ast-model.c
@@ -401,7 +401,7 @@ static gint
 ast_iter_n_children (GtkTreeModel *tree_model,
                           GtkTreeIter  *iter)
 {
-       AstNode  *node = iter->user_data;
+       AstNode  *node = iter ? iter->user_data : AST_NODE(tree_model);

        inspect_child_node(node);
        return node->childnodes->len;

Re: Best way to inspect the parse tree from Sparse

[Dibyendu Majumdar]

Hi Chris,

I am getting a different crash after making the change:

Starting program: /home/dylan/github/linux-sparse/test-inspect parse.c
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffede40700 (LWP 19684)]
[New Thread 0x7fffed63f700 (LWP 19685)]
[New Thread 0x7fffece3e700 (LWP 19686)]

Thread 1 "test-inspect" received signal SIGSEGV, Segmentation fault.
0x00007ffff6ed963b in __GI__IO_default_xsputn (f=0x7fffff7ff590,
    data=0x42aaf3, n=16) at genops.c:422
422    genops.c: No such file or directory.

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

Can you do a "ldd test-inspect"?

Which version of Ubuntu are you using? I think I need to get one of those to
test it.

Chris

On Wed, Aug 9, 2017 at 3:46 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi Chris,
>
> I am getting a different crash after making the change:
>
> Starting program: /home/dylan/github/linux-sparse/test-inspect parse.c
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> [New Thread 0x7fffede40700 (LWP 19684)]
> [New Thread 0x7fffed63f700 (LWP 19685)]
> [New Thread 0x7fffece3e700 (LWP 19686)]
>
> Thread 1 "test-inspect" received signal SIGSEGV, Segmentation fault.
> 0x00007ffff6ed963b in __GI__IO_default_xsputn (f=0x7fffff7ff590,
>     data=0x42aaf3, n=16) at genops.c:422
> 422    genops.c: No such file or directory.

Re: Best way to inspect the parse tree from Sparse

[Dibyendu Majumdar]

On 9 August 2017 at 12:57, Christopher Li <sparse@chrisli.org> wrote:
> Can you do a "ldd test-inspect"?
>
> Which version of Ubuntu are you using? I think I need to get one of those to
> test it.
>

I am using ubuntu 16.04 LTS.

Here is the output from ldd:

ldd ./test-inspect
    linux-vdso.so.1 =>  (0x00007ffd449d2000)
    libgtk-x11-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fbdf76d5000)
    libgobject-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007fbdf7482000)
    libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0
(0x00007fbdf7170000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbdf6da6000)
    libgdk-x11-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 (0x00007fbdf6af1000)
    libgmodule-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007fbdf68ec000)
    libpangocairo-1.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0 (0x00007fbdf66df000)
    libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fbdf63a5000)
    libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3
(0x00007fbdf619e000)
    libatk-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libatk-1.0.so.0
(0x00007fbdf5f79000)
    libcairo.so.2 => /usr/lib/x86_64-linux-gnu/libcairo.so.2
(0x00007fbdf5c65000)
    libgdk_pixbuf-2.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libgdk_pixbuf-2.0.so.0 (0x00007fbdf5a42000)
    libgio-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
(0x00007fbdf56ba000)
    libpangoft2-1.0.so.0 =>
/usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0 (0x00007fbdf54a4000)
    libpango-1.0.so.0 => /usr/lib/x86_64-linux-gnu/libpango-1.0.so.0
(0x00007fbdf5257000)
    libfontconfig.so.1 => /usr/lib/x86_64-linux-gnu/libfontconfig.so.1
(0x00007fbdf5014000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fbdf4d0b000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007fbdf4aed000)
    libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007fbdf48e5000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fbdf4674000)
    /lib64/ld-linux-x86-64.so.2 (0x000055ca0ccca000)
    libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1
(0x00007fbdf446a000)
    libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1
(0x00007fbdf4267000)
    libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x00007fbdf4057000)
    libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2
(0x00007fbdf3e4b000)
    libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1
(0x00007fbdf3c41000)
    libXcomposite.so.1 => /usr/lib/x86_64-linux-gnu/libXcomposite.so.1
(0x00007fbdf3a3e000)
    libXdamage.so.1 => /usr/lib/x86_64-linux-gnu/libXdamage.so.1
(0x00007fbdf383a000)
    libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007fbdf3628000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbdf3423000)
    libfreetype.so.6 => /usr/lib/x86_64-linux-gnu/libfreetype.so.6
(0x00007fbdf3179000)
    libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007fbdf2f57000)
    libpixman-1.so.0 => /usr/lib/x86_64-linux-gnu/libpixman-1.so.0
(0x00007fbdf2cae000)
    libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007fbdf2a89000)
    libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0
(0x00007fbdf2885000)
    libxcb-render.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-render.so.0
(0x00007fbdf267a000)
    libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbdf2460000)
    librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fbdf2258000)
    libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1
(0x00007fbdf2035000)
    libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fbdf1e1a000)
    libharfbuzz.so.0 => /usr/lib/x86_64-linux-gnu/libharfbuzz.so.0
(0x00007fbdf1bbc000)
    libthai.so.0 => /usr/lib/x86_64-linux-gnu/libthai.so.0 (0x00007fbdf19b2000)
    libexpat.so.1 => /lib/x86_64-linux-gnu/libexpat.so.1 (0x00007fbdf1789000)
    libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007fbdf1584000)
    libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6
(0x00007fbdf137e000)
    libgraphite2.so.3 => /usr/lib/x86_64-linux-gnu/libgraphite2.so.3
(0x00007fbdf1158000)
    libdatrie.so.1 => /usr/lib/x86_64-linux-gnu/libdatrie.so.1
(0x00007fbdf0f50000)

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

On Wed, Aug 9, 2017 at 4:03 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 9 August 2017 at 12:57, Christopher Li <sparse@chrisli.org> wrote:
>> Can you do a "ldd test-inspect"?
>>
>> Which version of Ubuntu are you using? I think I need to get one of those to
>> test it.
>>
>
> I am using ubuntu 16.04 LTS.
>
> Here is the output from ldd:
>
> ldd ./test-inspect
>     linux-vdso.so.1 =>  (0x00007ffd449d2000)
>     libgtk-x11-2.0.so.0 =>
> /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 (0x00007fbdf76d5000)
>     libgobject-2.0.so.0 =>

Thanks.

Your GTK lib looks good.

I will get a ubuntu 16.04 to reproduce it.

Thanks

Chris

Re: Best way to inspect the parse tree from Sparse

[Christopher Li]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

On Wed, Aug 9, 2017 at 4:03 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> On 9 August 2017 at 12:57, Christopher Li <sparse@chrisli.org> wrote:
>> Can you do a "ldd test-inspect"?
>>
>> Which version of Ubuntu are you using? I think I need to get one of those to
>> test it.
>>
>
> I am using ubuntu 16.04 LTS.
>


OK. I have install ubuntu 16.04 LTS and writing this email
on ubuntu now.

The first patch I send you should be correct. But I think
there is a bug in the updated version of ubuntu 16.04
libgtk2.0-dev. I am not able to reproduce it with the
fresh install libgtk2 but I can't go back now.

I can duplicate the crash with update to latest version.

It seems to me that, when I click on one sub item,
it is passing iter == NULL. That seems wrong.
It shouldn't pass iter == NULL for sub list item.

Again, I am not GUI developer at all. This
test-inspect is all my GUI skill at best already.

With the patch I send earlier, this cause the gtk
go into infinity loop of asking about the child
of the child. It is asking for child with iter==NULL.
So I get it the root node, gtk seems get confused
after that.

The patch I send out before obvious should be applied.

The good news is that, in Ubuntu 16.04. GTK3.0 does
not have this problem. I am able to run gtk3 and
test-inspect will not crash.

I attach the patch here. You can try it out.
Please let me know how it work out for you.

I am writing a patch for RC5 to compile with gtk3
if available.

Chris

[-- Attachment #2: 0001-switch-to-gtk3.patch --]
[-- Type: text/x-patch, Size: 1763 bytes --]

From 002cb50499ca64539d677e46f035a0d62ab981e1 Mon Sep 17 00:00:00 2001
From: Chris Li <chris@cool>
Date: Thu, 10 Aug 2017 15:34:14 -0400
Subject: [PATCH] switch to gtk3

---
 Makefile    | 6 +++---
 ast-model.c | 3 ++-
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 96e81c4..db410eb 100644
--- a/Makefile
+++ b/Makefile
@@ -30,7 +30,7 @@ HAVE_LIBXML:=$(shell $(PKG_CONFIG) --exists libxml-2.0 2>/dev/null && echo 'yes'
 HAVE_GCC_DEP:=$(shell touch .gcc-test.c && 				\
 		$(CC) -c -Wp,-MD,.gcc-test.d .gcc-test.c 2>/dev/null && \
 		echo 'yes'; rm -f .gcc-test.d .gcc-test.o .gcc-test.c)
-HAVE_GTK2:=$(shell $(PKG_CONFIG) --exists gtk+-2.0 2>/dev/null && echo 'yes')
+HAVE_GTK2:=$(shell $(PKG_CONFIG) --exists gtk+-3.0 2>/dev/null && echo 'yes')
 LLVM_CONFIG:=llvm-config
 HAVE_LLVM:=$(shell $(LLVM_CONFIG) --version >/dev/null 2>&1 && echo 'yes')
 
@@ -67,8 +67,8 @@ $(warning Your system does not have libxml, disabling c2xml)
 endif
 
 ifeq ($(HAVE_GTK2),yes)
-GTK2_CFLAGS := $(shell $(PKG_CONFIG) --cflags gtk+-2.0)
-GTK2_LIBS := $(shell $(PKG_CONFIG) --libs gtk+-2.0)
+GTK2_CFLAGS := $(shell $(PKG_CONFIG) --cflags gtk+-3.0)
+GTK2_LIBS := $(shell $(PKG_CONFIG) --libs gtk+-3.0)
 PROGRAMS += test-inspect
 INST_PROGRAMS += test-inspect
 test-inspect_EXTRA_DEPS := ast-model.o ast-view.o ast-inspect.o
diff --git a/ast-model.c b/ast-model.c
index 704c487..d7f0c3a 100644
--- a/ast-model.c
+++ b/ast-model.c
@@ -401,7 +401,8 @@ static gint
 ast_iter_n_children (GtkTreeModel *tree_model,
                           GtkTreeIter  *iter)
 {
-	AstNode  *node = iter->user_data;
+	AstNode  *node = iter ? iter->user_data
+				: AST_NODE(tree_model);
 
 	inspect_child_node(node);
 	return node->childnodes->len;
-- 
2.7.4