RFA: Ada-related patches, part I

RFA: Ada-related patches, part I

[Paul N. Hilfinger]

The following patch is the first in a series that will merge ACT's 
enhancements to GDB to support Ada (specifically, as compiled by
GNAT).  Aidan Skinner submitted these changes earlier, mostly to elicit 
comment, and we have acted on the comments received.  

The plan is first to add enough changes to the non- "ada-" files to allow
us to bring the latter up to date and then add them to the Makefile (so that
they actually get compiled when you build GDB).  We'll then hook things up
in stages, starting with expression evaluation, symbol lookup, 
and breakpoints (all of these involve some modifications in non "ada-" files).

This first patch introduces the "language_ada" constant to enum language,
some new symbols for enum exp_opcode, and some code in parse.c to 
process the latter.

Paul Hilfinger

ChangeLog: 

2003-03-03  Paul N. Hilfinger  <hilfingr@otisco.mckusick.com>

	* defs.h (enum language): Add language_ada.
	* 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.

Index: current-public.8/gdb/parse.c
--- current-public.8/gdb/parse.c Wed, 26 Feb 2003 23:03:21 -0800 hilfingr (GdbPub/t/b/0_parse.c 1.1.1.1 644)
+++ submit.4(w)/gdb/parse.c Fri, 28 Feb 2003 02:38:16 -0800 hilfingr (GdbPub/t/b/0_parse.c 1.1.1.1.1.1 644)
@@ -836,6 +836,16 @@ length_of_subexp (register struct expres
       args = 1 + longest_to_int (expr->elts[endpos - 2].longconst);
       break;
 
+    case OP_ADA_ATTRIBUTE:
+      oplen = 4;
+      args = 1 + longest_to_int (expr->elts[endpos - 3].longconst);
+      break;
+
+    case UNOP_IN_RANGE:
+      oplen = 3;
+      args = 1;
+      break;
+
     case UNOP_MAX:
     case UNOP_MIN:
       oplen = 3;
@@ -843,6 +853,7 @@ length_of_subexp (register struct expres
 
     case BINOP_VAL:
     case UNOP_CAST:
+    case UNOP_QUAL:
     case UNOP_MEMVAL:
       oplen = 3;
       args = 1;
@@ -891,6 +902,7 @@ length_of_subexp (register struct expres
     case TERNOP_COND:
     case TERNOP_SLICE:
     case TERNOP_SLICE_COUNT:
+    case TERNOP_IN_RANGE:
       args = 3;
       break;
 
@@ -901,6 +913,7 @@ length_of_subexp (register struct expres
       break;
 
     case BINOP_ASSIGN_MODIFY:
+    case BINOP_IN_BOUNDS:
       oplen = 3;
       args = 2;
       break;
@@ -981,13 +994,20 @@ prefixify_subexp (register struct expres
       args = 1 + longest_to_int (inexpr->elts[inend - 2].longconst);
       break;
 
+    case OP_ADA_ATTRIBUTE:
+      oplen = 4;
+      args = 1 + longest_to_int (inexpr->elts[inend - 3].longconst);
+      break;
+
     case UNOP_MIN:
     case UNOP_MAX:
       oplen = 3;
       break;
 
     case UNOP_CAST:
+    case UNOP_QUAL:
     case UNOP_MEMVAL:
+    case UNOP_IN_RANGE:
       oplen = 3;
       args = 1;
       break;
@@ -1032,6 +1052,7 @@ prefixify_subexp (register struct expres
       args += 1;
       break;
 
+    case TERNOP_IN_RANGE:
     case TERNOP_COND:
     case TERNOP_SLICE:
     case TERNOP_SLICE_COUNT:
@@ -1039,6 +1060,7 @@ prefixify_subexp (register struct expres
       break;
 
     case BINOP_ASSIGN_MODIFY:
+    case BINOP_IN_BOUNDS:
       oplen = 3;
       args = 2;
       break;
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.4(w)/gdb/expression.h Mon, 03 Mar 2003 22:39:22 -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++.  */
 
+    /* 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 ...) */
+    BINOP_IN_BOUNDS,
+
     /* For Modula-2 integer division DIV */
     BINOP_INTDIV,
 
@@ -133,6 +141,9 @@ enum exp_opcode
        OP2. */
     TERNOP_SLICE_COUNT,
 
+    /* Ada: X IN L .. 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,10 @@ enum exp_opcode
        It casts the value of the following subexpression.  */
     UNOP_CAST,
 
+    /* UNOP_QUAL is Ada type qualification.  It is encoded as for
+       UNOP_CAST, above, and denotes the TYPE'(EXPR) construct. */
+    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 +288,11 @@ enum exp_opcode
     /* (The deleted) Chill builtin functions.  */
     UNOP_LOWER, UNOP_UPPER, UNOP_LENGTH, UNOP_CARD, UNOP_CHMAX, UNOP_CHMIN,
 
+    /* Ada: 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). */
+    UNOP_IN_RANGE,
+ 
     OP_BOOL,			/* Modula-2 builtin BOOLEAN type */
     OP_M2_STRING,		/* Modula-2 string constants */
 
Index: current-public.8/gdb/defs.h
--- current-public.8/gdb/defs.h Mon, 03 Mar 2003 20:28:40 -0800 hilfingr (GdbPub/x/b/17_defs.h 1.1.1.1.1.1.2.1 644)
+++ submit.4(w)/gdb/defs.h Mon, 03 Mar 2003 22:11:24 -0800 hilfingr (GdbPub/x/b/17_defs.h 1.1.1.1.1.1.2.1.1.1 644)
@@ -211,7 +211,8 @@ enum language
     language_m2,		/* Modula-2 */
     language_asm,		/* Assembly language */
     language_scm,    		/* Scheme / Guile */
-    language_pascal		/* Pascal */
+    language_pascal,		/* Pascal */
+    language_ada		/* Ada */
   };
 
 enum precision_type

Re: RFA: Ada-related patches, part I

[Andrew Cagney]

> 2003-03-03  Paul N. Hilfinger  <hilfingr@otisco.mckusick.com>

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.

> 	* 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?

> 	* 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).

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

Andrew

Re: RFA: Ada-related patches, part I

[Eli Zaretskii]

> Date: Mon, 3 Mar 2003 23:37:13 -0800
> From: "Paul N. Hilfinger" <hilfingr@otisco.mckusick.com>
> 
> The following patch is the first in a series that will merge ACT's 
> enhancements to GDB to support Ada (specifically, as compiled by
> GNAT).  Aidan Skinner submitted these changes earlier, mostly to elicit 
> comment, and we have acted on the comments received.  
> 
> The plan is first to add enough changes to the non- "ada-" files to allow
> us to bring the latter up to date and then add them to the Makefile (so that
> they actually get compiled when you build GDB).  We'll then hook things up
> in stages, starting with expression evaluation, symbol lookup, 
> and breakpoints (all of these involve some modifications in non "ada-" files).

Please don't forget to update the manual as well.  At the very least
we should say where we list the supported languages that Ada is
supported.

TIA

Re: RFA: Ada-related patches, part I

[Paul N. Hilfinger]

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 */
 

Re: RFA: Ada-related patches, part I

[Andrew Cagney]

> 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.  

(insert std disclaimer `ignoring c++ ...')

> 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.

Yes.  Before adding another case to a switch, see of the code can be 
pushed into the language vector.

> 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.

Which ever.  The re-worded version is much better.

>> (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.

Wow! is there duplication or what.  Would adding a new operator 
`generic' that, in the expression array, added:
	OP_GENERIC (better name?)
	(operator *) op
	... op->length(exp) elements ...
work?  Something similar for the expression evaluator.

What about op_print?  I guess operator ends up containing similar 
information.

Andrew