Re: RFA: Ada-related patches, part I

["Paul N. Hilfinger" <hilfingr at otisco dot mckusick dot com>]

Andrew,

> You don't appear to have a personal assignment for GDB on file. 
> Assuming this is being done as an employee of Act, can you please use 
> your act e-mail address in your ChangLogs.

Sure, if that will simplify things.  For the record, however, 
otisco.mckusick.com is the property of Ada Core Technologies.

> > 	* defs.h (enum language): Add language_ada.
> 
> This is ok.
> 
> However, this change shouldn't be necessary.  The language code should 
> be sufficiently modula as to not need this.  Can you/act at least 
> investigate what would be needed to finish this?

Umm.  But I notice quite a few tests scattered around the current
sources having the form ``if (suchandsuch == language_cplus...).''  In
particular, there are uses in such routines as symbol_natural_name
that are going to have to be extended for Ada. Perhaps, then, I am a
bit unclear what you intend here.  

Are you simply saying that if I find a place in common (i.e., non ada-
*) files that requires different treatment for Ada than for another
language, I should introduce a new entry into the language_defn
structure to handle it object-orientedly rather than performing
specific ``... == language_ada'' tests?  I'm certainly all for that.

> > 	* expression.h (enum exp_opcode): Add definitions of 
> > 	OP_ADA_ATTRIBUTE, BINOP_IN_BOUNDS, TERNOP_IN_RANGE, UNOP_QUAL,
> > 	and UNOP_IN_RANGE.
> > 	* parse.c (length_of_subexp): Add cases for new definitions in
> > 	enum exp_opcode in expression.h.
> > 	(prefixify_subexp): Ditto.
> 
> The comments on these suggest ADA specific semantics.  Can you please 
> include ADA in all their names.  Otherwize approved (but a separate 
> commit to the above as this change is orthogonal).

Yes, I considered doing that, just as someone (you, as I recall) previously
asked for OP_ADA_ATTRIBUTE.  However, these operators make sense
generically; it's just that only Ada uses them at the moment.  
How's about if I change the comments instead to remove all 
traces of Ada (see below)?  Your choice.

> (mind you, again, this shouldn't be needed.  Instead these operators 
> should be objects that language specific modules can just add).

I think I agree again, and normally would have done just this as a matter
of course, except that parse.c is not set up to be extensible in this
way.  The functions prefixify_subexp and length_of_subexp both need to
know about these opcodes, as things now stand.  Of course, if you are
asking me to reorganize parse.c and to revise expression.h so as to
make the operator set open-ended, just say the word.

Paul


Index: current-public.8/gdb/expression.h
--- current-public.8/gdb/expression.h Tue, 21 Jan 2003 00:14:41 -0800 hilfingr (GdbPub/w/b/41_expression 1.1 644)
+++ submit.5(w)/gdb/expression.h Wed, 05 Mar 2003 00:09:52 -0800 hilfingr (GdbPub/w/b/41_expression 1.1.1.2 644)
@@ -50,7 +50,8 @@ enum exp_opcode
     OP_NULL,
 
 /* BINOP_... operate on two values computed by following subexpressions,
-   replacing them by one result value.  They take no immediate arguments.  */
+   replacing them by one result value.  Unless otherwise noted, 
+   they take no immediate arguments.  */
 
     BINOP_ADD,			/* + */
     BINOP_SUB,			/* - */
@@ -92,6 +93,13 @@ enum exp_opcode
 
     /* end of C++.  */
 
+    /* The two operands are an array, A, and an index value X.
+       Evaluates to true iff X is within range of the Nth dimension
+       (N>=1) of A. A multi-dimensional array type is represented 
+       as array of array of ....   The operator is followed by the
+       immediate operand N, followed again by BINOP_IN_BOUNDS.  */
+    BINOP_IN_BOUNDS,
+
     /* For Modula-2 integer division DIV */
     BINOP_INTDIV,
 
@@ -133,6 +141,9 @@ enum exp_opcode
        OP2. */
     TERNOP_SLICE_COUNT,
 
+    /* Three operands X, L, and U.  True iff L <= X <= U.  */
+    TERNOP_IN_RANGE,
+ 
     /* 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>.
@@ -200,6 +211,15 @@ enum exp_opcode
        literal. It is followed by exactly two args that are doubles.  */
     OP_COMPLEX,
 
+    /* Ada attribute call.  OP_ADA_ATTRIBUTE is followed by an integer
+       in the next exp_element, which is the number of extra arguments
+       to the attribute (thus, x'tag would specify 0, whereas x'length
+       would specify 1).  The integer is followed by another integer
+       indicating the identity of the attribute (of type enum
+       ada_attribute, see ada-lang.h), and then by a repeat of
+       OP_ADA_ATTRIBUTE */
+    OP_ADA_ATTRIBUTE,
+
     /* 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
@@ -228,6 +248,13 @@ enum exp_opcode
        It casts the value of the following subexpression.  */
     UNOP_CAST,
 
+    /* Takes a single expression operand, EXPR, and an immediate 
+       operand TYPE, encoded like UNOP_CAST, above.  Returns EXPR with
+       the type TYPE, but without performing any conversions.  Also 
+       indicates that EXPR is to be evaluated in a context expecting
+       TYPE. */
+    UNOP_QUAL,
+
     /* 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
@@ -264,6 +291,11 @@ enum exp_opcode
     /* (The deleted) Chill builtin functions.  */
     UNOP_LOWER, UNOP_UPPER, UNOP_LENGTH, UNOP_CARD, UNOP_CHMAX, UNOP_CHMIN,
 
+    /* True iff operand X is a member of type TYPE (typically a
+       subrange).   The `TYPE' argument is immediate, with 
+       UNOP_IN_RANGE before and after it.  */
+    UNOP_IN_RANGE,
+ 
     OP_BOOL,			/* Modula-2 builtin BOOLEAN type */
     OP_M2_STRING,		/* Modula-2 string constants */