[RFC] MI varobj testsuite support

[RFC] MI varobj testsuite support

[Keith Seitz]

Hi,

I believe that Andrew (and others, myself included) have been less than 
satisfied with how time-consuming it is to write varobj tests for MI. By 
their very nature, the output is rather verbose and quite complicated.

I've whipped up a little something to facilitate writing tests, and I 
would appreciate comments about it. (Even if it's just as simple as: "I 
like it -- submit the patch!")

This is stolen from the comments in the file, explaining how to use the 
basic create/children procedures (only thing I've implemented so far).

Keith

# This module defines support routines that can be used by the MI
# testsuite to facilitate the testing of the varobj interface.
#
# The public commands of this module take at least two arguments: a
# KEY to direct the type of output and a variable specification (VARSPEC)
# which describes the (root) variable.

# The most basic varspec is simply a Tcl list of the variable's type, its 
# "name" and a list of its children. For example, consider the following
# variable declaration in C:
#
# int foo;
#
# The varspec to fully describe this variable would be:
#
# set foo_varspec {
#   int foo {}
# }
#
# To get the MI testsuite to test the creation of this varobj, one would
# use the command Varobj::create with the "command" and "pattern" keys
# with mi_gdb_test:
#
# mi_gdb_test [Varobj::create command $foo_varspec] \
#   [Varobj::create pattern $foo_varspec] \
#   "create varobj for foo"

# Consider a more complex example:
#
# class B
# {
# public:
#   int pub_b;
# protected:
#   char *prot_b;
# };
#
# class A : public B
# {
# public:
#   int pub_a;
# private:
#   int priv_a[3];
# };
#
# A varspec describing a variable "bar" of type "class A" would look like:
#
# set bar_varspec {
#   A bar {
#     B B {
#       public {
#         int pub_b {}
#       }
#       protected {
#         {char *} prot_b {
#           char *prot_b {}
#         }
#       }
#     }
#     {} public {
#       int pub_a {}
#     }
#     {} private {
#        {int [3]} priv_a {
#          int 0 {}
#          int 1 {}
#          int 2 {}
#        }
#      }
#    }
#  }
#
# To test the creation of this varobj, simply use:
# mi_gdb_test [Varobj::create command $bar_varspec] \
#   [Varobj::create pattern $bar_varspec] \
#   "create varobj for bar"
#
# To get this children of this varobj:
# mi_gdb_test [Varobj::children command $bar_varspec] \
#  [Varobj::children pattern $bar_varspec] \
#  "get children of bar"
#
# To test getting the children of "B", simply use:
# mi_gdb_test [Varobj::children command $bar_varspec B] \
#   [Varobj::children pattern $bar_varspec B] \
#   "get children of bar.B"
#
# Finally, to get the children of one of the children of bar, specify
# the child's name as a period-delimited path through the varspec:
# mi_gdb_test [Varobj::children command $bar_varspec B.protected.prot_b] \
#   [Varobj::children pattern $bar_varspec B.protected.prot_b] \
#   "get children of bar.B.protected.prot_b"

Re: [RFC] MI varobj testsuite support

[Fernando Nasser]

Keith,

What about the other commands like -var-info-num-children, -var-update, 
etc.?  Would we still use the old way?

I have the impression that the command part is not really useful.  We 
could live with the pattern part only.

Fernando

Keith Seitz wrote:
> Hi,
> 
> I believe that Andrew (and others, myself included) have been less than 
> satisfied with how time-consuming it is to write varobj tests for MI. By 
> their very nature, the output is rather verbose and quite complicated.
> 
> I've whipped up a little something to facilitate writing tests, and I 
> would appreciate comments about it. (Even if it's just as simple as: "I 
> like it -- submit the patch!")
> 
> This is stolen from the comments in the file, explaining how to use the 
> basic create/children procedures (only thing I've implemented so far).
> 
> Keith
> 
> # This module defines support routines that can be used by the MI
> # testsuite to facilitate the testing of the varobj interface.
> #
> # The public commands of this module take at least two arguments: a
> # KEY to direct the type of output and a variable specification (VARSPEC)
> # which describes the (root) variable.
> 
> # The most basic varspec is simply a Tcl list of the variable's type, its 
> # "name" and a list of its children. For example, consider the following
> # variable declaration in C:
> #
> # int foo;
> #
> # The varspec to fully describe this variable would be:
> #
> # set foo_varspec {
> #   int foo {}
> # }
> #
> # To get the MI testsuite to test the creation of this varobj, one would
> # use the command Varobj::create with the "command" and "pattern" keys
> # with mi_gdb_test:
> #
> # mi_gdb_test [Varobj::create command $foo_varspec] \
> #   [Varobj::create pattern $foo_varspec] \
> #   "create varobj for foo"
> 
> # Consider a more complex example:
> #
> # class B
> # {
> # public:
> #   int pub_b;
> # protected:
> #   char *prot_b;
> # };
> #
> # class A : public B
> # {
> # public:
> #   int pub_a;
> # private:
> #   int priv_a[3];
> # };
> #
> # A varspec describing a variable "bar" of type "class A" would look like:
> #
> # set bar_varspec {
> #   A bar {
> #     B B {
> #       public {
> #         int pub_b {}
> #       }
> #       protected {
> #         {char *} prot_b {
> #           char *prot_b {}
> #         }
> #       }
> #     }
> #     {} public {
> #       int pub_a {}
> #     }
> #     {} private {
> #        {int [3]} priv_a {
> #          int 0 {}
> #          int 1 {}
> #          int 2 {}
> #        }
> #      }
> #    }
> #  }
> #
> # To test the creation of this varobj, simply use:
> # mi_gdb_test [Varobj::create command $bar_varspec] \
> #   [Varobj::create pattern $bar_varspec] \
> #   "create varobj for bar"
> #
> # To get this children of this varobj:
> # mi_gdb_test [Varobj::children command $bar_varspec] \
> #  [Varobj::children pattern $bar_varspec] \
> #  "get children of bar"
> #
> # To test getting the children of "B", simply use:
> # mi_gdb_test [Varobj::children command $bar_varspec B] \
> #   [Varobj::children pattern $bar_varspec B] \
> #   "get children of bar.B"
> #
> # Finally, to get the children of one of the children of bar, specify
> # the child's name as a period-delimited path through the varspec:
> # mi_gdb_test [Varobj::children command $bar_varspec B.protected.prot_b] \
> #   [Varobj::children pattern $bar_varspec B.protected.prot_b] \
> #   "get children of bar.B.protected.prot_b"
> 
> 
> 


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: [RFC] MI varobj testsuite support

[Keith Seitz]

On Thu, 17 Oct 2002, Fernando Nasser wrote:

> What about the other commands like -var-info-num-children, -var-update, 
> etc.?  Would we still use the old way?

No, I simply haven't added those yet. I wanted to request comments about 
whether anyone really wanted/cared to have such a thing submitted.

> I have the impression that the command part is not really useful.  We 
> could live with the pattern part only.

The reason the command part exists is to facilitate command construction 
across multiple versions of MI. It is also used to pin down the names of 
the varobjs.

It's only a convenience. I find it easier to write "Varobj::create foo" 
than "-var-create foo * foo"; I can never remember the whole syntax 
without looking it up.

I can whack it before submitting.
Keith

Re: [RFC] MI varobj testsuite support

[Fernando Nasser]

Keith Seitz wrote:
> It's only a convenience. I find it easier to write "Varobj::create foo" 
> than "-var-create foo * foo"; I can never remember the whole syntax 
> without looking it up.
> 

I am concerned with the legibility of the tests and when people may be 
reproducing parts of it by hand.  The "-var-create foo * foo" is better 
for that.

The other commands generate a very simple output that is easy to create 
an pattern for and it is also easier for human interpretation (same 
situation as above).

The "pattern" part is cool though.  Why don't you submit just that for 
now?

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9