Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [RFC 1/2] merge std-operator.def & ada-operator.def into one file.
  2012-03-16 23:21 RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
  2012-03-16 23:21 ` [RFC 2/2] Remove op_name callback in struct exp_descriptor Joel Brobecker
@ 2012-03-16 23:21 ` Joel Brobecker
  2012-03-16 23:29 ` RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
  2012-03-19  8:46 ` Jan Kratochvil
  3 siblings, 0 replies; 9+ messages in thread
From: Joel Brobecker @ 2012-03-16 23:21 UTC (permalink / raw)
  To: gdb-patches; +Cc: Joel Brobecker

gdb/ChangeLog:

        * operator.def: New file, merging std-operator.def and
        ada-operator.def.
        * std-operator.def, ada-operator.def: Delete.
        * expression.h (enum exp_opcode): Include "operator.def" instead
        of "std-operator.def" and "ada-operator.def".  OP_EXTENDED0 is
        now also provided by operator.def.
        * expprint.c (op_name_standard): Include "operator.def" instead
        of "std-operator.def".

This introduces a small change of behavior, in the fact that
op_name_standard will now recognize Ada operators. But this function
is about to be renamed to "op_name", so I think it's OK.


---
 gdb/ada-operator.def |   99 ------------
 gdb/expprint.c       |    2 +-
 gdb/expression.h     |   12 +--
 gdb/operator.def     |  414 ++++++++++++++++++++++++++++++++++++++++++++++++++
 gdb/std-operator.def |  328 ---------------------------------------
 5 files changed, 416 insertions(+), 439 deletions(-)
 delete mode 100644 gdb/ada-operator.def
 create mode 100644 gdb/operator.def
 delete mode 100644 gdb/std-operator.def

diff --git a/gdb/ada-operator.def b/gdb/ada-operator.def
deleted file mode 100644
index 8738250..0000000
--- a/gdb/ada-operator.def
+++ /dev/null
@@ -1,99 +0,0 @@
-/* Ada language operator definitions for GDB, the GNU debugger.
-
-   Copyright (C) 1992, 1997-2005, 2007-2012 Free Software Foundation,
-   Inc.
-
-   This file is part of GDB.
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 3 of the License, or
-   (at your option) any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   You should have received a copy of the GNU General Public License
-   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
-
-/* X IN A'RANGE(N).  N is an immediate operand, surrounded by 
-   BINOP_IN_BOUNDS before and after.  A is an array, X an index 
-   value.  Evaluates to true iff X is within range of the Nth
-   dimension (1-based) of A.  (A multi-dimensional array
-   type is represented as array of array of ...) */
-OP (BINOP_IN_BOUNDS)
-
-/* X IN L .. U.  True iff L <= X <= U.  */
-OP (TERNOP_IN_RANGE)
-
-/* Ada attributes ('Foo). */
-OP (OP_ATR_FIRST)
-OP (OP_ATR_LAST)
-OP (OP_ATR_LENGTH)
-OP (OP_ATR_IMAGE)
-OP (OP_ATR_MAX)
-OP (OP_ATR_MIN)
-OP (OP_ATR_MODULUS)
-OP (OP_ATR_POS)
-OP (OP_ATR_SIZE)
-OP (OP_ATR_TAG)
-OP (OP_ATR_VAL)
-
-/* Ada type qualification.  It is encoded as for UNOP_CAST, above, 
-   and denotes the TYPE'(EXPR) construct. */
-OP (UNOP_QUAL)
-
-/* X IN TYPE.  The `TYPE' argument is immediate, with 
-   UNOP_IN_RANGE before and after it. True iff X is a member of 
-   type TYPE (typically a subrange). */
-OP (UNOP_IN_RANGE)
-
-/* An aggregate.   A single immediate operand, N>0, gives
-   the number of component specifications that follow.  The
-   immediate operand is followed by a second OP_AGGREGATE.  
-   Next come N component specifications.  A component
-   specification is either an OP_OTHERS (others=>...), an
-   OP_CHOICES (for named associations), or other expression (for
-   positional aggregates only).  Aggregates currently
-   occur only as the right sides of assignments. */
-OP (OP_AGGREGATE)
-
-/* An others clause.  Followed by a single expression. */
-OP (OP_OTHERS)
-
-/* An aggregate component association.  A single immediate operand, N, 
-   gives the number of choices that follow.  This is followed by a second
-   OP_CHOICES operator.  Next come N operands, each of which is an
-   expression, an OP_DISCRETE_RANGE, or an OP_NAME---the latter 
-   for a simple name that must be a record component name and does 
-   not correspond to a single existing symbol.  After the N choice 
-   indicators comes an expression giving the value.
-
-   In an aggregate such as (X => E1, ...), where X is a simple
-   name, X could syntactically be either a component_selector_name 
-   or an expression used as a discrete_choice, depending on the
-   aggregate's type context.  Since this is not known at parsing
-   time, we don't attempt to disambiguate X if it has multiple
-   definitions, but instead supply an OP_NAME.  If X has a single
-   definition, we represent it with an OP_VAR_VALUE, even though
-   it may turn out to be within a record aggregate.  Aggregate 
-   evaluation can use either OP_NAMEs or OP_VAR_VALUEs to get a
-   record field name, and can evaluate OP_VAR_VALUE normally to
-   get its value as an expression.  Unfortunately, we lose out in
-   cases where X has multiple meanings and is part of an array
-   aggregate.  I hope these are not common enough to annoy users,
-   who can work around the problem in any case by putting
-   parentheses around X. */
-OP (OP_CHOICES)
-
-/* A positional aggregate component association.  The operator is 
-   followed by a single integer indicating the position in the 
-   aggregate (0-based), followed by a second OP_POSITIONAL.  Next 
-   follows a single expression giving the component value.  */
-OP (OP_POSITIONAL)
-
-/* A range of values.  Followed by two expressions giving the
-   upper and lower bounds of the range. */
-OP (OP_DISCRETE_RANGE)
diff --git a/gdb/expprint.c b/gdb/expprint.c
index fd1fccb..2f97cc0 100644
--- a/gdb/expprint.c
+++ b/gdb/expprint.c
@@ -675,7 +675,7 @@ op_name_standard (enum exp_opcode opcode)
 #define OP(name)	\
     case name:		\
       return #name ;
-#include "std-operator.def"
+#include "operator.def"
 #undef OP
     }
 }
diff --git a/gdb/expression.h b/gdb/expression.h
index 1f878ce..f45b705 100644
--- a/gdb/expression.h
+++ b/gdb/expression.h
@@ -44,17 +44,7 @@
 enum exp_opcode
   {
 #define OP(name) name ,
-
-#include "std-operator.def"
-
-    /* First extension operator.  Individual language modules define extra
-       operators in *.def include files below with numbers higher than
-       OP_EXTENDED0.  */
-    OP (OP_EXTENDED0)
-
-/* Language specific operators.  */
-#include "ada-operator.def"
-
+#include "operator.def"
 #undef OP
 
     /* Existing only to swallow the last comma (',') from last .inc file.  */
diff --git a/gdb/operator.def b/gdb/operator.def
new file mode 100644
index 0000000..fa3b501
--- /dev/null
+++ b/gdb/operator.def
@@ -0,0 +1,414 @@
+/* Standard language operator definitions for GDB, the GNU debugger.
+
+   Copyright (C) 1986, 1989, 1992, 1994, 2000, 2003, 2005, 2007-2012
+   Free Software Foundation, Inc.
+
+   This file is part of GDB.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
+
+/* Used when it's necessary to pass an opcode which will be ignored,
+   or to catch uninitialized values.  */
+OP (OP_NULL)
+
+/* BINOP_... operate on two values computed by following subexpressions,
+replacing them by one result value.  They take no immediate arguments.  */
+
+OP (BINOP_ADD)			/* + */
+OP (BINOP_SUB)			/* - */
+OP (BINOP_MUL)			/* * */
+OP (BINOP_DIV)			/* / */
+OP (BINOP_REM)			/* % */
+OP (BINOP_MOD)			/* mod (Knuth 1.2.4) */
+OP (BINOP_LSH)			/* << */
+OP (BINOP_RSH)			/* >> */
+OP (BINOP_LOGICAL_AND)		/* && */
+OP (BINOP_LOGICAL_OR)		/* || */
+OP (BINOP_BITWISE_AND)		/* & */
+OP (BINOP_BITWISE_IOR)		/* | */
+OP (BINOP_BITWISE_XOR)		/* ^ */
+OP (BINOP_EQUAL)		/* == */
+OP (BINOP_NOTEQUAL)		/* != */
+OP (BINOP_LESS)			/* < */
+OP (BINOP_GTR)			/* > */
+OP (BINOP_LEQ)			/* <= */
+OP (BINOP_GEQ)			/* >= */
+OP (BINOP_REPEAT)		/* @ */
+OP (BINOP_ASSIGN)		/* = */
+OP (BINOP_COMMA)		/* , */
+OP (BINOP_SUBSCRIPT)		/* x[y] */
+OP (BINOP_EXP)			/* Exponentiation */
+
+/* C++.  */
+
+OP (BINOP_MIN)			/* <? */
+OP (BINOP_MAX)			/* >? */
+
+/* STRUCTOP_MEMBER is used for pointer-to-member constructs.
+   X .  * Y translates into X STRUCTOP_MEMBER Y.  */
+OP (STRUCTOP_MEMBER)
+
+/* STRUCTOP_MPTR is used for pointer-to-member constructs
+   when X is a pointer instead of an aggregate.  */
+OP (STRUCTOP_MPTR)
+
+/* TYPE_INSTANCE is used when the user specifies a specific
+   type instantiation for overloaded methods/functions.
+
+   The format is:
+   TYPE_INSTANCE num_types type0 ... typeN num_types TYPE_INSTANCE.  */
+OP (TYPE_INSTANCE)
+
+/* end of C++.  */
+
+/* For Modula-2 integer division DIV.  */
+OP (BINOP_INTDIV)
+
+/* +=, -=, *=, and so on.  The following exp_element is another opcode,
+   a BINOP_, saying how to modify.  Then comes another BINOP_ASSIGN_MODIFY,
+   making three exp_elements in total.  */
+OP (BINOP_ASSIGN_MODIFY)
+
+/* Modula-2 standard (binary) procedures.  */
+OP (BINOP_VAL)
+
+/* Concatenate two operands, such as character strings or bitstrings.
+   If the first operand is a integer expression, then it means concatenate
+   the second operand with itself that many times.  */
+OP (BINOP_CONCAT)
+
+/* For (the deleted) Chill and Pascal.  */
+OP (BINOP_IN)			/* Returns 1 iff ARG1 IN ARG2.  */
+
+/* This is the "colon operator" used various places in (the
+   deleted) Chill.  */
+OP (BINOP_RANGE)
+
+/* This must be the highest BINOP_ value, for expprint.c.  */
+OP (BINOP_END)
+
+/* Operates on three values computed by following subexpressions.  */
+OP (TERNOP_COND)		/* ?: */
+
+/* A sub-string/sub-array.  (the deleted) Chill syntax:
+   OP1(OP2:OP3).  Return elements OP2 through OP3 of OP1.  */
+OP (TERNOP_SLICE)
+
+/* A sub-string/sub-array.  (The deleted) Chill syntax: OP1(OP2 UP
+   OP3).  Return OP3 elements of OP1, starting with element
+   OP2.  */
+OP (TERNOP_SLICE_COUNT)
+
+/* Multidimensional subscript operator, such as Modula-2 x[a,b,...].
+   The dimensionality is encoded in the operator, like the number of
+   function arguments in OP_FUNCALL, I.E. <OP><dimension><OP>.
+   The value of the first following subexpression is subscripted
+   by each of the next following subexpressions, one per dimension.  */
+OP (MULTI_SUBSCRIPT)
+
+/* The OP_... series take immediate following arguments.
+   After the arguments come another OP_... (the same one)
+   so that the grouping can be recognized from the end.  */
+
+/* OP_LONG is followed by a type pointer in the next exp_element
+   and the long constant value in the following exp_element.
+   Then comes another OP_LONG.
+   Thus, the operation occupies four exp_elements.  */
+OP (OP_LONG)
+
+/* OP_DOUBLE is similar but takes a DOUBLEST constant instead of a
+   long.  */
+OP (OP_DOUBLE)
+
+/* OP_VAR_VALUE takes one struct block * in the following element,
+   and one struct symbol * in the following exp_element, followed
+   by another OP_VAR_VALUE, making four exp_elements.  If the
+   block is non-NULL, evaluate the symbol relative to the
+   innermost frame executing in that block; if the block is NULL
+   use the selected frame.  */
+OP (OP_VAR_VALUE)
+
+/* OP_VAR_ENTRY_VALUE takes one struct symbol * in the following element,
+   followed by another OP_VAR_ENTRY_VALUE, making three exp_elements.
+   somename@entry may mean parameter value as present at the entry of the
+   current function.  Implemented via DW_OP_GNU_entry_value.  */
+OP (OP_VAR_ENTRY_VALUE)
+
+/* OP_LAST is followed by an integer in the next exp_element.
+   The integer is zero for the last value printed,
+   or it is the absolute number of a history element.
+   With another OP_LAST at the end, this makes three exp_elements.  */
+OP (OP_LAST)
+
+/* OP_REGISTER is followed by a string in the next exp_element.
+   This is the name of a register to fetch.  */
+OP (OP_REGISTER)
+
+/* OP_INTERNALVAR is followed by an internalvar ptr in the next
+   exp_element.  With another OP_INTERNALVAR at the end, this
+   makes three exp_elements.  */
+OP (OP_INTERNALVAR)
+
+/* OP_FUNCALL is followed by an integer in the next exp_element.
+   The integer is the number of args to the function call.
+   That many plus one values from following subexpressions
+   are used, the first one being the function.
+   The integer is followed by a repeat of OP_FUNCALL,
+   making three exp_elements.  */
+OP (OP_FUNCALL)
+
+/* OP_OBJC_MSGCALL is followed by a string in the next exp_element
+   and then an integer.  The string is the selector string.  The
+   integer is the number of arguments to the message call.  That
+   many plus one values are used, the first one being the object
+   pointer.  This is an Objective C message.  */
+OP (OP_OBJC_MSGCALL)
+
+/* This is EXACTLY like OP_FUNCALL but is semantically different.
+   In F77, array subscript expressions, substring expressions and
+   function calls are all exactly the same syntactically.  They
+   may only be disambiguated at runtime.  Thus this operator,
+   which indicates that we have found something of the form
+   <name> ( <stuff> ).  */
+OP (OP_F77_UNDETERMINED_ARGLIST)
+
+/* OP_COMPLEX takes a type in the following element, followed by another
+   OP_COMPLEX, making three exp_elements.  It is followed by two double
+   args, and converts them into a complex number of the given type.  */
+OP (OP_COMPLEX)
+
+/* OP_STRING represents a string constant.
+   Its format is the same as that of a STRUCTOP, but the string
+   data is just made into a string constant when the operation
+   is executed.  */
+OP (OP_STRING)
+
+/* OP_BITSTRING represents a packed bitstring constant.
+   Its format is the same as that of a STRUCTOP, but the bitstring
+   data is just made into a bitstring constant when the operation
+   is executed.  */
+OP (OP_BITSTRING)
+
+/* OP_ARRAY creates an array constant out of the following subexpressions.
+   It is followed by two exp_elements, the first containing an integer
+   that is the lower bound of the array and the second containing another
+   integer that is the upper bound of the array.  The second integer is
+   followed by a repeat of OP_ARRAY, making four exp_elements total.
+   The bounds are used to compute the number of following subexpressions
+   to consume, as well as setting the bounds in the created array constant.
+   The type of the elements is taken from the type of the first subexp,
+   and they must all match.  */
+OP (OP_ARRAY)
+
+/* UNOP_CAST is followed by a type pointer in the next exp_element.
+   With another UNOP_CAST at the end, this makes three exp_elements.
+   It casts the value of the following subexpression.  */
+OP (UNOP_CAST)
+
+/* The C++ dynamic_cast operator.  */
+OP (UNOP_DYNAMIC_CAST)
+
+/* The C++ reinterpret_cast operator.  */
+OP (UNOP_REINTERPRET_CAST)
+
+/* UNOP_MEMVAL is followed by a type pointer in the next exp_element
+   With another UNOP_MEMVAL at the end, this makes three exp_elements.
+   It casts the contents of the word addressed by the value of the
+   following subexpression.  */
+OP (UNOP_MEMVAL)
+
+/* UNOP_MEMVAL_TLS is followed by a `struct objfile' pointer in the next
+   exp_element and a type pointer in the following exp_element.
+   With another UNOP_MEMVAL_TLS at the end, this makes four exp_elements.
+   It casts the contents of the word offsetted by the value of the
+   following subexpression from the TLS specified by `struct objfile'.  */
+OP (UNOP_MEMVAL_TLS)
+
+/* UNOP_... operate on one value from a following subexpression
+   and replace it with a result.  They take no immediate arguments.  */
+
+OP (UNOP_NEG)			/* Unary - */
+OP (UNOP_LOGICAL_NOT)		/* Unary ! */
+OP (UNOP_COMPLEMENT)		/* Unary ~ */
+OP (UNOP_IND)			/* Unary * */
+OP (UNOP_ADDR)			/* Unary & */
+OP (UNOP_PREINCREMENT)		/* ++ before an expression */
+OP (UNOP_POSTINCREMENT)		/* ++ after an expression */
+OP (UNOP_PREDECREMENT)		/* -- before an expression */
+OP (UNOP_POSTDECREMENT)		/* -- after an expression */
+OP (UNOP_SIZEOF)		/* Unary sizeof (followed by expression) */
+
+OP (UNOP_PLUS)			/* Unary plus */
+
+OP (UNOP_CAP)			/* Modula-2 standard (unary) procedures */
+OP (UNOP_CHR)
+OP (UNOP_ORD)
+OP (UNOP_ABS)
+OP (UNOP_FLOAT)
+OP (UNOP_HIGH)
+OP (UNOP_MAX)
+OP (UNOP_MIN)
+OP (UNOP_ODD)
+OP (UNOP_TRUNC)
+
+OP (OP_BOOL)			/* Modula-2 builtin BOOLEAN type */
+OP (OP_M2_STRING)		/* Modula-2 string constants */
+
+/* STRUCTOP_... operate on a value from a following subexpression
+   by extracting a structure component specified by a string
+   that appears in the following exp_elements (as many as needed).
+   STRUCTOP_STRUCT is used for "." and STRUCTOP_PTR for "->".
+   They differ only in the error message given in case the value is
+   not suitable or the structure component specified is not found.
+
+   The length of the string follows the opcode, followed by
+   BYTES_TO_EXP_ELEM(length) elements containing the data of the
+   string, followed by the length again and the opcode again.  */
+
+OP (STRUCTOP_STRUCT)
+OP (STRUCTOP_PTR)
+
+/* C++: OP_THIS is just a placeholder for the class instance variable.
+   It just comes in a tight (OP_THIS, OP_THIS) pair.  */
+OP (OP_THIS)
+
+/* Objective C: "@selector" pseudo-operator.  */
+OP (OP_OBJC_SELECTOR)
+
+/* OP_SCOPE surrounds a type name and a field name.  The type
+   name is encoded as one element, but the field name stays as
+   a string, which, of course, is variable length.  */
+OP (OP_SCOPE)
+
+/* Used to represent named structure field values in brace
+   initializers (or tuples as they are called in (the deleted)
+   Chill).
+
+   The gcc C syntax is NAME:VALUE or .NAME=VALUE, the (the
+   deleted) Chill syntax is .NAME:VALUE.  Multiple labels (as in
+   the (the deleted) Chill syntax .NAME1,.NAME2:VALUE) is
+   represented as if it were .NAME1:(.NAME2:VALUE) (though that is
+   not valid (the deleted) Chill syntax).
+
+   The NAME is represented as for STRUCTOP_STRUCT;  VALUE follows.  */
+OP (OP_LABELED)
+
+/* OP_TYPE is for parsing types, and used with the "ptype" command
+   so we can look up types that are qualified by scope, either with
+   the GDB "::" operator, or the Modula-2 '.' operator.  */
+OP (OP_TYPE)
+
+/* An un-looked-up identifier.  */
+OP (OP_NAME)
+
+/* An Objective C Foundation Class NSString constant.  */
+OP (OP_OBJC_NSSTRING)
+
+/* A F90 array range operator (for "exp:exp", "exp:", ":exp" and ":").  */
+OP (OP_F90_RANGE)
+
+/* OP_DECFLOAT is followed by a type pointer in the next exp_element
+   and a dec long constant value in the following exp_element.
+   Then comes another OP_DECFLOAT.  */
+OP (OP_DECFLOAT)
+
+/* OP_ADL_FUNC specifies that the function is to be looked up in an
+   Argument Dependent manner (Koenig lookup).  */
+OP (OP_ADL_FUNC)
+
+/* First extension operator.  Individual language modules define extra
+   operators below with numbers higher than OP_EXTENDED0.  */
+OP (OP_EXTENDED0)
+
+/* Ada */
+
+/* X IN A'RANGE(N).  N is an immediate operand, surrounded by 
+   BINOP_IN_BOUNDS before and after.  A is an array, X an index 
+   value.  Evaluates to true iff X is within range of the Nth
+   dimension (1-based) of A.  (A multi-dimensional array
+   type is represented as array of array of ...) */
+OP (BINOP_IN_BOUNDS)
+
+/* X IN L .. U.  True iff L <= X <= U.  */
+OP (TERNOP_IN_RANGE)
+
+/* Ada attributes ('Foo). */
+OP (OP_ATR_FIRST)
+OP (OP_ATR_LAST)
+OP (OP_ATR_LENGTH)
+OP (OP_ATR_IMAGE)
+OP (OP_ATR_MAX)
+OP (OP_ATR_MIN)
+OP (OP_ATR_MODULUS)
+OP (OP_ATR_POS)
+OP (OP_ATR_SIZE)
+OP (OP_ATR_TAG)
+OP (OP_ATR_VAL)
+
+/* Ada type qualification.  It is encoded as for UNOP_CAST, above, 
+   and denotes the TYPE'(EXPR) construct. */
+OP (UNOP_QUAL)
+
+/* X IN TYPE.  The `TYPE' argument is immediate, with 
+   UNOP_IN_RANGE before and after it. True iff X is a member of 
+   type TYPE (typically a subrange). */
+OP (UNOP_IN_RANGE)
+
+/* An aggregate.   A single immediate operand, N>0, gives
+   the number of component specifications that follow.  The
+   immediate operand is followed by a second OP_AGGREGATE.  
+   Next come N component specifications.  A component
+   specification is either an OP_OTHERS (others=>...), an
+   OP_CHOICES (for named associations), or other expression (for
+   positional aggregates only).  Aggregates currently
+   occur only as the right sides of assignments. */
+OP (OP_AGGREGATE)
+
+/* An others clause.  Followed by a single expression. */
+OP (OP_OTHERS)
+
+/* An aggregate component association.  A single immediate operand, N, 
+   gives the number of choices that follow.  This is followed by a second
+   OP_CHOICES operator.  Next come N operands, each of which is an
+   expression, an OP_DISCRETE_RANGE, or an OP_NAME---the latter 
+   for a simple name that must be a record component name and does 
+   not correspond to a single existing symbol.  After the N choice 
+   indicators comes an expression giving the value.
+
+   In an aggregate such as (X => E1, ...), where X is a simple
+   name, X could syntactically be either a component_selector_name 
+   or an expression used as a discrete_choice, depending on the
+   aggregate's type context.  Since this is not known at parsing
+   time, we don't attempt to disambiguate X if it has multiple
+   definitions, but instead supply an OP_NAME.  If X has a single
+   definition, we represent it with an OP_VAR_VALUE, even though
+   it may turn out to be within a record aggregate.  Aggregate 
+   evaluation can use either OP_NAMEs or OP_VAR_VALUEs to get a
+   record field name, and can evaluate OP_VAR_VALUE normally to
+   get its value as an expression.  Unfortunately, we lose out in
+   cases where X has multiple meanings and is part of an array
+   aggregate.  I hope these are not common enough to annoy users,
+   who can work around the problem in any case by putting
+   parentheses around X. */
+OP (OP_CHOICES)
+
+/* A positional aggregate component association.  The operator is 
+   followed by a single integer indicating the position in the 
+   aggregate (0-based), followed by a second OP_POSITIONAL.  Next 
+   follows a single expression giving the component value.  */
+OP (OP_POSITIONAL)
+
+/* A range of values.  Followed by two expressions giving the
+   upper and lower bounds of the range. */
+OP (OP_DISCRETE_RANGE)
diff --git a/gdb/std-operator.def b/gdb/std-operator.def
deleted file mode 100644
index f2f650b..0000000
--- a/gdb/std-operator.def
+++ /dev/null
@@ -1,328 +0,0 @@
-/* Standard language operator definitions for GDB, the GNU debugger.
-
-   Copyright (C) 1986, 1989, 1992, 1994, 2000, 2003, 2005, 2007-2012
-   Free Software Foundation, Inc.
-
-   This file is part of GDB.
-
-   This program is free software; you can redistribute it and/or modify
-   it under the terms of the GNU General Public License as published by
-   the Free Software Foundation; either version 3 of the License, or
-   (at your option) any later version.
-
-   This program is distributed in the hope that it will be useful,
-   but WITHOUT ANY WARRANTY; without even the implied warranty of
-   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-   GNU General Public License for more details.
-
-   You should have received a copy of the GNU General Public License
-   along with this program.  If not, see <http://www.gnu.org/licenses/>.  */
-
-/* Used when it's necessary to pass an opcode which will be ignored,
-   or to catch uninitialized values.  */
-OP (OP_NULL)
-
-/* BINOP_... operate on two values computed by following subexpressions,
-replacing them by one result value.  They take no immediate arguments.  */
-
-OP (BINOP_ADD)			/* + */
-OP (BINOP_SUB)			/* - */
-OP (BINOP_MUL)			/* * */
-OP (BINOP_DIV)			/* / */
-OP (BINOP_REM)			/* % */
-OP (BINOP_MOD)			/* mod (Knuth 1.2.4) */
-OP (BINOP_LSH)			/* << */
-OP (BINOP_RSH)			/* >> */
-OP (BINOP_LOGICAL_AND)		/* && */
-OP (BINOP_LOGICAL_OR)		/* || */
-OP (BINOP_BITWISE_AND)		/* & */
-OP (BINOP_BITWISE_IOR)		/* | */
-OP (BINOP_BITWISE_XOR)		/* ^ */
-OP (BINOP_EQUAL)		/* == */
-OP (BINOP_NOTEQUAL)		/* != */
-OP (BINOP_LESS)			/* < */
-OP (BINOP_GTR)			/* > */
-OP (BINOP_LEQ)			/* <= */
-OP (BINOP_GEQ)			/* >= */
-OP (BINOP_REPEAT)		/* @ */
-OP (BINOP_ASSIGN)		/* = */
-OP (BINOP_COMMA)		/* , */
-OP (BINOP_SUBSCRIPT)		/* x[y] */
-OP (BINOP_EXP)			/* Exponentiation */
-
-/* C++.  */
-
-OP (BINOP_MIN)			/* <? */
-OP (BINOP_MAX)			/* >? */
-
-/* STRUCTOP_MEMBER is used for pointer-to-member constructs.
-   X .  * Y translates into X STRUCTOP_MEMBER Y.  */
-OP (STRUCTOP_MEMBER)
-
-/* STRUCTOP_MPTR is used for pointer-to-member constructs
-   when X is a pointer instead of an aggregate.  */
-OP (STRUCTOP_MPTR)
-
-/* TYPE_INSTANCE is used when the user specifies a specific
-   type instantiation for overloaded methods/functions.
-
-   The format is:
-   TYPE_INSTANCE num_types type0 ... typeN num_types TYPE_INSTANCE.  */
-OP (TYPE_INSTANCE)
-
-/* end of C++.  */
-
-/* For Modula-2 integer division DIV.  */
-OP (BINOP_INTDIV)
-
-/* +=, -=, *=, and so on.  The following exp_element is another opcode,
-   a BINOP_, saying how to modify.  Then comes another BINOP_ASSIGN_MODIFY,
-   making three exp_elements in total.  */
-OP (BINOP_ASSIGN_MODIFY)
-
-/* Modula-2 standard (binary) procedures.  */
-OP (BINOP_VAL)
-
-/* Concatenate two operands, such as character strings or bitstrings.
-   If the first operand is a integer expression, then it means concatenate
-   the second operand with itself that many times.  */
-OP (BINOP_CONCAT)
-
-/* For (the deleted) Chill and Pascal.  */
-OP (BINOP_IN)			/* Returns 1 iff ARG1 IN ARG2.  */
-
-/* This is the "colon operator" used various places in (the
-   deleted) Chill.  */
-OP (BINOP_RANGE)
-
-/* This must be the highest BINOP_ value, for expprint.c.  */
-OP (BINOP_END)
-
-/* Operates on three values computed by following subexpressions.  */
-OP (TERNOP_COND)		/* ?: */
-
-/* A sub-string/sub-array.  (the deleted) Chill syntax:
-   OP1(OP2:OP3).  Return elements OP2 through OP3 of OP1.  */
-OP (TERNOP_SLICE)
-
-/* A sub-string/sub-array.  (The deleted) Chill syntax: OP1(OP2 UP
-   OP3).  Return OP3 elements of OP1, starting with element
-   OP2.  */
-OP (TERNOP_SLICE_COUNT)
-
-/* Multidimensional subscript operator, such as Modula-2 x[a,b,...].
-   The dimensionality is encoded in the operator, like the number of
-   function arguments in OP_FUNCALL, I.E. <OP><dimension><OP>.
-   The value of the first following subexpression is subscripted
-   by each of the next following subexpressions, one per dimension.  */
-OP (MULTI_SUBSCRIPT)
-
-/* The OP_... series take immediate following arguments.
-   After the arguments come another OP_... (the same one)
-   so that the grouping can be recognized from the end.  */
-
-/* OP_LONG is followed by a type pointer in the next exp_element
-   and the long constant value in the following exp_element.
-   Then comes another OP_LONG.
-   Thus, the operation occupies four exp_elements.  */
-OP (OP_LONG)
-
-/* OP_DOUBLE is similar but takes a DOUBLEST constant instead of a
-   long.  */
-OP (OP_DOUBLE)
-
-/* OP_VAR_VALUE takes one struct block * in the following element,
-   and one struct symbol * in the following exp_element, followed
-   by another OP_VAR_VALUE, making four exp_elements.  If the
-   block is non-NULL, evaluate the symbol relative to the
-   innermost frame executing in that block; if the block is NULL
-   use the selected frame.  */
-OP (OP_VAR_VALUE)
-
-/* OP_VAR_ENTRY_VALUE takes one struct symbol * in the following element,
-   followed by another OP_VAR_ENTRY_VALUE, making three exp_elements.
-   somename@entry may mean parameter value as present at the entry of the
-   current function.  Implemented via DW_OP_GNU_entry_value.  */
-OP (OP_VAR_ENTRY_VALUE)
-
-/* OP_LAST is followed by an integer in the next exp_element.
-   The integer is zero for the last value printed,
-   or it is the absolute number of a history element.
-   With another OP_LAST at the end, this makes three exp_elements.  */
-OP (OP_LAST)
-
-/* OP_REGISTER is followed by a string in the next exp_element.
-   This is the name of a register to fetch.  */
-OP (OP_REGISTER)
-
-/* OP_INTERNALVAR is followed by an internalvar ptr in the next
-   exp_element.  With another OP_INTERNALVAR at the end, this
-   makes three exp_elements.  */
-OP (OP_INTERNALVAR)
-
-/* OP_FUNCALL is followed by an integer in the next exp_element.
-   The integer is the number of args to the function call.
-   That many plus one values from following subexpressions
-   are used, the first one being the function.
-   The integer is followed by a repeat of OP_FUNCALL,
-   making three exp_elements.  */
-OP (OP_FUNCALL)
-
-/* OP_OBJC_MSGCALL is followed by a string in the next exp_element
-   and then an integer.  The string is the selector string.  The
-   integer is the number of arguments to the message call.  That
-   many plus one values are used, the first one being the object
-   pointer.  This is an Objective C message.  */
-OP (OP_OBJC_MSGCALL)
-
-/* This is EXACTLY like OP_FUNCALL but is semantically different.
-   In F77, array subscript expressions, substring expressions and
-   function calls are all exactly the same syntactically.  They
-   may only be disambiguated at runtime.  Thus this operator,
-   which indicates that we have found something of the form
-   <name> ( <stuff> ).  */
-OP (OP_F77_UNDETERMINED_ARGLIST)
-
-/* OP_COMPLEX takes a type in the following element, followed by another
-   OP_COMPLEX, making three exp_elements.  It is followed by two double
-   args, and converts them into a complex number of the given type.  */
-OP (OP_COMPLEX)
-
-/* OP_STRING represents a string constant.
-   Its format is the same as that of a STRUCTOP, but the string
-   data is just made into a string constant when the operation
-   is executed.  */
-OP (OP_STRING)
-
-/* OP_BITSTRING represents a packed bitstring constant.
-   Its format is the same as that of a STRUCTOP, but the bitstring
-   data is just made into a bitstring constant when the operation
-   is executed.  */
-OP (OP_BITSTRING)
-
-/* OP_ARRAY creates an array constant out of the following subexpressions.
-   It is followed by two exp_elements, the first containing an integer
-   that is the lower bound of the array and the second containing another
-   integer that is the upper bound of the array.  The second integer is
-   followed by a repeat of OP_ARRAY, making four exp_elements total.
-   The bounds are used to compute the number of following subexpressions
-   to consume, as well as setting the bounds in the created array constant.
-   The type of the elements is taken from the type of the first subexp,
-   and they must all match.  */
-OP (OP_ARRAY)
-
-/* UNOP_CAST is followed by a type pointer in the next exp_element.
-   With another UNOP_CAST at the end, this makes three exp_elements.
-   It casts the value of the following subexpression.  */
-OP (UNOP_CAST)
-
-/* The C++ dynamic_cast operator.  */
-OP (UNOP_DYNAMIC_CAST)
-
-/* The C++ reinterpret_cast operator.  */
-OP (UNOP_REINTERPRET_CAST)
-
-/* UNOP_MEMVAL is followed by a type pointer in the next exp_element
-   With another UNOP_MEMVAL at the end, this makes three exp_elements.
-   It casts the contents of the word addressed by the value of the
-   following subexpression.  */
-OP (UNOP_MEMVAL)
-
-/* UNOP_MEMVAL_TLS is followed by a `struct objfile' pointer in the next
-   exp_element and a type pointer in the following exp_element.
-   With another UNOP_MEMVAL_TLS at the end, this makes four exp_elements.
-   It casts the contents of the word offsetted by the value of the
-   following subexpression from the TLS specified by `struct objfile'.  */
-OP (UNOP_MEMVAL_TLS)
-
-/* UNOP_... operate on one value from a following subexpression
-   and replace it with a result.  They take no immediate arguments.  */
-
-OP (UNOP_NEG)			/* Unary - */
-OP (UNOP_LOGICAL_NOT)		/* Unary ! */
-OP (UNOP_COMPLEMENT)		/* Unary ~ */
-OP (UNOP_IND)			/* Unary * */
-OP (UNOP_ADDR)			/* Unary & */
-OP (UNOP_PREINCREMENT)		/* ++ before an expression */
-OP (UNOP_POSTINCREMENT)		/* ++ after an expression */
-OP (UNOP_PREDECREMENT)		/* -- before an expression */
-OP (UNOP_POSTDECREMENT)		/* -- after an expression */
-OP (UNOP_SIZEOF)		/* Unary sizeof (followed by expression) */
-
-OP (UNOP_PLUS)			/* Unary plus */
-
-OP (UNOP_CAP)			/* Modula-2 standard (unary) procedures */
-OP (UNOP_CHR)
-OP (UNOP_ORD)
-OP (UNOP_ABS)
-OP (UNOP_FLOAT)
-OP (UNOP_HIGH)
-OP (UNOP_MAX)
-OP (UNOP_MIN)
-OP (UNOP_ODD)
-OP (UNOP_TRUNC)
-
-OP (OP_BOOL)			/* Modula-2 builtin BOOLEAN type */
-OP (OP_M2_STRING)		/* Modula-2 string constants */
-
-/* STRUCTOP_... operate on a value from a following subexpression
-   by extracting a structure component specified by a string
-   that appears in the following exp_elements (as many as needed).
-   STRUCTOP_STRUCT is used for "." and STRUCTOP_PTR for "->".
-   They differ only in the error message given in case the value is
-   not suitable or the structure component specified is not found.
-
-   The length of the string follows the opcode, followed by
-   BYTES_TO_EXP_ELEM(length) elements containing the data of the
-   string, followed by the length again and the opcode again.  */
-
-OP (STRUCTOP_STRUCT)
-OP (STRUCTOP_PTR)
-
-/* C++: OP_THIS is just a placeholder for the class instance variable.
-   It just comes in a tight (OP_THIS, OP_THIS) pair.  */
-OP (OP_THIS)
-
-/* Objective C: "@selector" pseudo-operator.  */
-OP (OP_OBJC_SELECTOR)
-
-/* OP_SCOPE surrounds a type name and a field name.  The type
-   name is encoded as one element, but the field name stays as
-   a string, which, of course, is variable length.  */
-OP (OP_SCOPE)
-
-/* Used to represent named structure field values in brace
-   initializers (or tuples as they are called in (the deleted)
-   Chill).
-
-   The gcc C syntax is NAME:VALUE or .NAME=VALUE, the (the
-   deleted) Chill syntax is .NAME:VALUE.  Multiple labels (as in
-   the (the deleted) Chill syntax .NAME1,.NAME2:VALUE) is
-   represented as if it were .NAME1:(.NAME2:VALUE) (though that is
-   not valid (the deleted) Chill syntax).
-
-   The NAME is represented as for STRUCTOP_STRUCT;  VALUE follows.  */
-OP (OP_LABELED)
-
-/* OP_TYPE is for parsing types, and used with the "ptype" command
-   so we can look up types that are qualified by scope, either with
-   the GDB "::" operator, or the Modula-2 '.' operator.  */
-OP (OP_TYPE)
-
-/* An un-looked-up identifier.  */
-OP (OP_NAME)
-
-/* An Objective C Foundation Class NSString constant.  */
-OP (OP_OBJC_NSSTRING)
-
-/* A F90 array range operator (for "exp:exp", "exp:", ":exp" and ":").  */
-OP (OP_F90_RANGE)
-
-/* OP_DECFLOAT is followed by a type pointer in the next exp_element
-   and a dec long constant value in the following exp_element.
-   Then comes another OP_DECFLOAT.  */
-OP (OP_DECFLOAT)
-
-/* OP_ADL_FUNC specifies that the function is to be looked up in an
-   Argument Dependent manner (Koenig lookup).  */
-OP (OP_ADL_FUNC)
-- 
1.7.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

* [RFC 2/2] Remove op_name callback in struct exp_descriptor.
  2012-03-16 23:21 RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
@ 2012-03-16 23:21 ` Joel Brobecker
  2012-03-16 23:21 ` [RFC 1/2] merge std-operator.def & ada-operator.def into one file Joel Brobecker
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 9+ messages in thread
From: Joel Brobecker @ 2012-03-16 23:21 UTC (permalink / raw)
  To: gdb-patches; +Cc: Joel Brobecker

This callback really isn't necessary anymore, since all opcodes are
now defined within one single file.  So it's easy to write a function
that prints the image of the opcode without having to know the language.

This patch does the following:

  * Delete function "op_name";
  * Rename "op_name_standard" into "op_name", and update all callers;
  * Remove the "op_name" callback from struct exp_descriptor and
    update all instantiations.

gdb/ChangeLog:

        * parser-defs.h (op_name_standard): Delete declaration.
        (struct exp_descriptor): Remove field "op_name".
        * expression.h (op_name): Update declaration.
        * expprint.c (op_name): Delete.
        (op_name_standard): Renamed into "op_name".
        (dump_raw_expression, dump_subexp): Update call to op_name.
        * c-lang.c (exp_descriptor_c): Remove entry for field "op_name".
        * jv-lang.c (exp_descriptor_java): Likewise.
        * m2-lang.c (exp_descriptor_modula2): Ditto.
        * opencl-lang.c (exp_descriptor_opencl): Ditto.
        * parse.c (exp_descriptor_standard): Ditto.
        * ada-lang.c (ada_op_name): Delete.
        (ada_exp_descriptor): Remove entry for field "op_name".
        * ax-gdb.c (gen_expr): Update call to op_name.

---
 gdb/ada-lang.c    |   24 ------------------------
 gdb/ax-gdb.c      |    2 +-
 gdb/c-lang.c      |    1 -
 gdb/expprint.c    |   14 +++-----------
 gdb/expression.h  |    2 +-
 gdb/jv-lang.c     |    1 -
 gdb/m2-lang.c     |    1 -
 gdb/opencl-lang.c |    1 -
 gdb/parse.c       |    1 -
 gdb/parser-defs.h |    5 -----
 10 files changed, 5 insertions(+), 47 deletions(-)

diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c
index c8c388b..85d7907 100644
--- a/gdb/ada-lang.c
+++ b/gdb/ada-lang.c
@@ -132,8 +132,6 @@ static void replace_operator_with_call (struct expression **, int, int, int,
 
 static int possible_user_operator_p (enum exp_opcode, struct value **);
 
-static char *ada_op_name (enum exp_opcode);
-
 static const char *ada_decoded_op_name (enum exp_opcode);
 
 static int numeric_type_p (struct type *);
@@ -12685,27 +12683,6 @@ ada_operator_check (struct expression *exp, int pos,
   return 0;
 }
 
-static char *
-ada_op_name (enum exp_opcode opcode)
-{
-  switch (opcode)
-    {
-    default:
-      return op_name_standard (opcode);
-
-#define OP_DEFN(op, len, args, binop) case op: return #op;
-      ADA_OPERATORS;
-#undef OP_DEFN
-
-    case OP_AGGREGATE:
-      return "OP_AGGREGATE";
-    case OP_CHOICES:
-      return "OP_CHOICES";
-    case OP_NAME:
-      return "OP_NAME";
-    }
-}
-
 /* As for operator_length, but assumes PC is pointing at the first
    element of the operator, and gives meaningful results only for the 
    Ada-specific operators, returning 0 for *OPLENP and *ARGSP otherwise.  */
@@ -13078,7 +13055,6 @@ static const struct exp_descriptor ada_exp_descriptor = {
   ada_print_subexp,
   ada_operator_length,
   ada_operator_check,
-  ada_op_name,
   ada_dump_subexp_body,
   ada_evaluate_subexp
 };
diff --git a/gdb/ax-gdb.c b/gdb/ax-gdb.c
index aaefed6..e543f69 100644
--- a/gdb/ax-gdb.c
+++ b/gdb/ax-gdb.c
@@ -2217,7 +2217,7 @@ gen_expr (struct expression *exp, union exp_element **pc,
 
     default:
       error (_("Unsupported operator %s (%d) in expression."),
-	     op_name (exp, op), op);
+	     op_name (op), op);
     }
 }
 
diff --git a/gdb/c-lang.c b/gdb/c-lang.c
index b43d1af..6dcb99c 100644
--- a/gdb/c-lang.c
+++ b/gdb/c-lang.c
@@ -822,7 +822,6 @@ const struct exp_descriptor exp_descriptor_c =
   print_subexp_standard,
   operator_length_standard,
   operator_check_standard,
-  op_name_standard,
   dump_subexp_body_standard,
   evaluate_subexp_c
 };
diff --git a/gdb/expprint.c b/gdb/expprint.c
index 2f97cc0..9fdde9b 100644
--- a/gdb/expprint.c
+++ b/gdb/expprint.c
@@ -649,19 +649,11 @@ op_string (enum exp_opcode op)
 
 static int dump_subexp_body (struct expression *exp, struct ui_file *, int);
 
-/* Name for OPCODE, when it appears in expression EXP.  */
-
-char *
-op_name (struct expression *exp, enum exp_opcode opcode)
-{
-  return exp->language_defn->la_exp_desc->op_name (opcode);
-}
-
 /* Default name for the standard operator OPCODE (i.e., one defined in
    the definition of enum exp_opcode).  */
 
 char *
-op_name_standard (enum exp_opcode opcode)
+op_name (enum exp_opcode opcode)
 {
   switch (opcode)
     {
@@ -704,7 +696,7 @@ dump_raw_expression (struct expression *exp, struct ui_file *stream,
   for (elt = 0; elt < exp->nelts; elt++)
     {
       fprintf_filtered (stream, "\t%5d  ", elt);
-      opcode_name = op_name (exp, exp->elts[elt].opcode);
+      opcode_name = op_name (exp->elts[elt].opcode);
 
       fprintf_filtered (stream, "%20s  ", opcode_name);
       print_longest (stream, 'd', 0, exp->elts[elt].longconst);
@@ -739,7 +731,7 @@ dump_subexp (struct expression *exp, struct ui_file *stream, int elt)
     fprintf_filtered (stream, " ");
   indent += 2;
 
-  fprintf_filtered (stream, "%-20s  ", op_name (exp, exp->elts[elt].opcode));
+  fprintf_filtered (stream, "%-20s  ", op_name (exp->elts[elt].opcode));
 
   elt = dump_subexp_body (exp, stream, elt);
 
diff --git a/gdb/expression.h b/gdb/expression.h
index f45b705..3553b51 100644
--- a/gdb/expression.h
+++ b/gdb/expression.h
@@ -129,7 +129,7 @@ extern struct value *evaluate_subexp_standard
 
 extern void print_expression (struct expression *, struct ui_file *);
 
-extern char *op_name (struct expression *exp, enum exp_opcode opcode);
+extern char *op_name (enum exp_opcode opcode);
 
 extern char *op_string (enum exp_opcode);
 
diff --git a/gdb/jv-lang.c b/gdb/jv-lang.c
index 280a3af..b6514bb 100644
--- a/gdb/jv-lang.c
+++ b/gdb/jv-lang.c
@@ -1156,7 +1156,6 @@ const struct exp_descriptor exp_descriptor_java =
   print_subexp_standard,
   operator_length_standard,
   operator_check_standard,
-  op_name_standard,
   dump_subexp_body_standard,
   evaluate_subexp_java
 };
diff --git a/gdb/m2-lang.c b/gdb/m2-lang.c
index c76d3ea..2a194cd 100644
--- a/gdb/m2-lang.c
+++ b/gdb/m2-lang.c
@@ -360,7 +360,6 @@ const struct exp_descriptor exp_descriptor_modula2 =
   print_subexp_standard,
   operator_length_standard,
   operator_check_standard,
-  op_name_standard,
   dump_subexp_body_standard,
   evaluate_subexp_modula2
 };
diff --git a/gdb/opencl-lang.c b/gdb/opencl-lang.c
index d5cd058..0c13e26 100644
--- a/gdb/opencl-lang.c
+++ b/gdb/opencl-lang.c
@@ -983,7 +983,6 @@ const struct exp_descriptor exp_descriptor_opencl =
   print_subexp_standard,
   operator_length_standard,
   operator_check_standard,
-  op_name_standard,
   dump_subexp_body_standard,
   evaluate_subexp_opencl
 };
diff --git a/gdb/parse.c b/gdb/parse.c
index e0fa1f3..6a52762 100644
--- a/gdb/parse.c
+++ b/gdb/parse.c
@@ -62,7 +62,6 @@ const struct exp_descriptor exp_descriptor_standard =
     print_subexp_standard,
     operator_length_standard,
     operator_check_standard,
-    op_name_standard,
     dump_subexp_body_standard,
     evaluate_subexp_standard
   };
diff --git a/gdb/parser-defs.h b/gdb/parser-defs.h
index 16b40ac..e5121a4 100644
--- a/gdb/parser-defs.h
+++ b/gdb/parser-defs.h
@@ -195,8 +195,6 @@ extern int operator_check_standard (struct expression *exp, int pos,
 				      (struct objfile *objfile, void *data),
 				    void *data);
 
-extern char *op_name_standard (enum exp_opcode);
-
 extern struct type *follow_types (struct type *);
 
 extern void null_post_parser (struct expression **, int);
@@ -281,9 +279,6 @@ struct exp_descriptor
 						void *data),
 			   void *data);
 
-    /* Name of this operator for dumping purposes.  */
-    char *(*op_name) (enum exp_opcode);
-
     /* Dump the rest of this (prefix) expression after the operator
        itself has been printed.  See dump_subexp_body_standard in
        (expprint.c).  */
-- 
1.7.1


^ permalink raw reply	[flat|nested] 9+ messages in thread

* RFC: merge std-operator.def and ada-operator.def?
@ 2012-03-16 23:21 Joel Brobecker
  2012-03-16 23:21 ` [RFC 2/2] Remove op_name callback in struct exp_descriptor Joel Brobecker
                   ` (3 more replies)
  0 siblings, 4 replies; 9+ messages in thread
From: Joel Brobecker @ 2012-03-16 23:21 UTC (permalink / raw)
  To: gdb-patches

Hello,

This is something I noticed while investigating something else: There
is no public function that prints a string image of an exp_opcode
enum. Digging deeper, I found "op_name", and eventually made it non-
static. I also found op_name_standard, but it only handled "standard"
opcodes, which, in pratice, means everything-but-Ada.

Thinking about all this, and knowing the fact that std-operator actually
also contains some language-specific operators as well (Eg Fortran's
OP_F90_RANGE), it seemed to me that this separation was causing some
unnecessary complexity in our code. The basic observation is that, to
print an opcode, you had to go through the language vector.

This patch mini-series simplifies all this.  Two steps:
  1. Merge std-operator.def and ada-operator.def into one "operator.def";
  2. Delete the "op_name" language-specific callback in struct
     struct exp_descriptor, and make some simplications that this
     change enables.

I would be tempted to add a third pass, which would rename "op_name"
into something a little more meaningful, such as "opcode_img", or
"opcode_image" or "opcode2str", so as not to confuse it with
expprint.c:op_string which does something entirely different
(ie converts BINOP_LOGICAL_OR into "||", for instance), and may
in fact return NULL even for valid opcodes.  This third step would
not be a very large patch, since the number of callers is very small.

The patch series was tested on x86_64-linux, no regression.
Thoughts?



^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: merge std-operator.def and ada-operator.def?
  2012-03-16 23:21 RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
  2012-03-16 23:21 ` [RFC 2/2] Remove op_name callback in struct exp_descriptor Joel Brobecker
  2012-03-16 23:21 ` [RFC 1/2] merge std-operator.def & ada-operator.def into one file Joel Brobecker
@ 2012-03-16 23:29 ` Joel Brobecker
  2012-03-19  8:46 ` Jan Kratochvil
  3 siblings, 0 replies; 9+ messages in thread
From: Joel Brobecker @ 2012-03-16 23:29 UTC (permalink / raw)
  To: gdb-patches

> This is something I noticed while investigating something else:
[...]
> The patch series was tested on x86_64-linux, no regression.

I wish I had sent patches in a different order... I should mention
that this patch series won't apply unless this other patch is applied:

    http://www.sourceware.org/ml/gdb-patches/2012-03/msg00644.html

It would be easy to fix, but I don't think ordering is going to be
an issue...

-- 
Joel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: merge std-operator.def and ada-operator.def?
  2012-03-16 23:21 RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
                   ` (2 preceding siblings ...)
  2012-03-16 23:29 ` RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
@ 2012-03-19  8:46 ` Jan Kratochvil
  2012-03-19 15:34   ` Joel Brobecker
  3 siblings, 1 reply; 9+ messages in thread
From: Jan Kratochvil @ 2012-03-19  8:46 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

Hi Joel,

On Sat, 17 Mar 2012 00:20:59 +0100, Joel Brobecker wrote:
> Thinking about all this, and knowing the fact that std-operator actually
> also contains some language-specific operators as well (Eg Fortran's
> OP_F90_RANGE), it seemed to me that this separation was causing some
> unnecessary complexity in our code.

(a) It would make some sense with GDB plugins but that plan was IIRC abandoned
    in the favor of Python scripting.

(b) The Ada operators should be at least very each marked as Ada specific in
    its definition comment.  Moreover I believe it would be worth really
    renaming them all to OP_ADA_* instead.


Unrelated to this patchset:
After I changed it to the *.def files with OP_* names ctags no longer work to
jump to OP_* definitions.  But I do not see how to fix that.


Thanks,
Jan


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: merge std-operator.def and ada-operator.def?
  2012-03-19  8:46 ` Jan Kratochvil
@ 2012-03-19 15:34   ` Joel Brobecker
  2012-03-19 15:40     ` Jan Kratochvil
  0 siblings, 1 reply; 9+ messages in thread
From: Joel Brobecker @ 2012-03-19 15:34 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: gdb-patches

> (a) It would make some sense with GDB plugins but that plan was IIRC abandoned
>     in the favor of Python scripting.
> 
> (b) The Ada operators should be at least very each marked as Ada specific in
>     its definition comment.  Moreover I believe it would be worth really
>     renaming them all to OP_ADA_* instead.

I am OK with renaming them using OP_ADA_ as a prefix, but I would
go the other way.  Instead of having language-specific operators,
make them available to everyone with standard, well documented,
semantics. Many of them might be only used in Ada at the moment,
but I think that's OK and there is no reason that some operators
such as "UNOP_IN_RANGE" for instance might not be used by other
languages.

-- 
Joel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: merge std-operator.def and ada-operator.def?
  2012-03-19 15:34   ` Joel Brobecker
@ 2012-03-19 15:40     ` Jan Kratochvil
  2012-03-19 15:50       ` Joel Brobecker
  0 siblings, 1 reply; 9+ messages in thread
From: Jan Kratochvil @ 2012-03-19 15:40 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

On Mon, 19 Mar 2012 16:33:47 +0100, Joel Brobecker wrote:
> I am OK with renaming them using OP_ADA_ as a prefix, but I would
> go the other way.  Instead of having language-specific operators,
> make them available to everyone with standard, well documented,
> semantics. Many of them might be only used in Ada at the moment,
> but I think that's OK and there is no reason that some operators
> such as "UNOP_IN_RANGE" for instance might not be used by other
> languages.

I am not so in favor of it.  Anything than can be made more specific with the
same user-visible functionality should be made so.  It simplifies maintenance.
This is the exact reason why I wanted to mark them as OP_ADA_*.

I understand putting the code into generic parts is easier for you.


Thanks,
Jan


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: merge std-operator.def and ada-operator.def?
  2012-03-19 15:40     ` Jan Kratochvil
@ 2012-03-19 15:50       ` Joel Brobecker
  2012-03-19 15:58         ` Jan Kratochvil
  0 siblings, 1 reply; 9+ messages in thread
From: Joel Brobecker @ 2012-03-19 15:50 UTC (permalink / raw)
  To: Jan Kratochvil; +Cc: gdb-patches

> I am not so in favor of it.  Anything than can be made more specific with the
> same user-visible functionality should be made so.  It simplifies maintenance.
> This is the exact reason why I wanted to mark them as OP_ADA_*.
> 
> I understand putting the code into generic parts is easier for you.

I am not doing this because it makes it easier for me; what started
this was the realization that some of the code looks unnecessarily
complex, or not even necessary at all. While I agree with you on
the general principle that language-specific features should be
clearly marked, in this case, I draw from Tom and I's experience with
the type handling and the language vector. Part of the language vector
and the associated complexity would be unnecessary if Ada was more
standard, rather than some side-entity that needs to be plugged into
the core system.

That being said, it's not terribly important to me that some opcodes
are going to be labeled "ADA". It's going to be a bit of a pain for
a while to keep AdaCore's sources in sync, but not difficult. So let's
not discuss this too much and decide what we want to do:

    1. Do we want to go with the propose patch series (merging the def
       files, and then simplifying a bit the code afterwards)?

    2. Do we want to rename the Ada opcodes? I can do that as a third
       patch, for instance.

-- 
Joel


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: RFC: merge std-operator.def and ada-operator.def?
  2012-03-19 15:50       ` Joel Brobecker
@ 2012-03-19 15:58         ` Jan Kratochvil
  0 siblings, 0 replies; 9+ messages in thread
From: Jan Kratochvil @ 2012-03-19 15:58 UTC (permalink / raw)
  To: Joel Brobecker; +Cc: gdb-patches

Hi Joel,

On Mon, 19 Mar 2012 16:49:41 +0100, Joel Brobecker wrote:
> I draw from Tom and I's experience with the type handling and the language
> vector. Part of the language vector and the associated complexity would be
> unnecessary if Ada was more standard, rather than some side-entity that
> needs to be plugged into the core system.

I actively maintain the counterpart dynamic types implementation for Fortran
(contrary to Ada) - archer-jankratochvil-vla.  I understand it is a second
class citizen as it is not merged in FSF GDB (contrary to Ada) but I find
unfair to just make the dynamic types of Ada "the standard" and let's see what
happens next.  Primarily because personally I find the DWARF expressions based
dynamic types of archer-jankratochvil-vla the more seamless solution for GDB
dynamic types in general.


>     1. Do we want to go with the propose patch series (merging the def
>        files, and then simplifying a bit the code afterwards)?
> 
>     2. Do we want to rename the Ada opcodes? I can do that as a third
>        patch, for instance.

I do not mind the order of the chosen steps, I just did not want to happen it
as described in the previous paragraph.


Thanks,
Jan


^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2012-03-19 15:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-16 23:21 RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
2012-03-16 23:21 ` [RFC 2/2] Remove op_name callback in struct exp_descriptor Joel Brobecker
2012-03-16 23:21 ` [RFC 1/2] merge std-operator.def & ada-operator.def into one file Joel Brobecker
2012-03-16 23:29 ` RFC: merge std-operator.def and ada-operator.def? Joel Brobecker
2012-03-19  8:46 ` Jan Kratochvil
2012-03-19 15:34   ` Joel Brobecker
2012-03-19 15:40     ` Jan Kratochvil
2012-03-19 15:50       ` Joel Brobecker
2012-03-19 15:58         ` Jan Kratochvil

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox