[RFC/RFA] gdb extension for Harvard architectures

[RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

This is an extension to help with debugging on Harvard architectures
(machines with two or more address spaces, typically one for 
instructions and one for data).  The idea here is to provide the user 
with a mechanism for specifying the address space of a pointer or
a raw address (eg. to display the contents of code memory as opposed
to data memory, when the address alone is not enough to differentiate).

Rather than provide extensions for specific commands such as print
and examine, it seemed more useful and general to provide an 
extension to the syntax for type expressions.  Thus we can identify
a pointer to (say) code address space by using a pointer cast, and
that expression can be used in any command that accepts an expression.

	(gdb) x /xb (@code short *) foo
	(gdb) print *(@data char *) 0x1000
	(gdb) set *(@code long long *) 0x1000 = 0

The idea is that the modifiers "@code" and "@data" can be used
anywhere where it would be legal to use "const" or "volatile".
I've used the "@" character to remove the new keywords from the
user name space, but I'm open to discussion on that choice
("$" might be another possibility).

So, for instance, a (@code int *) would be a pointer to an int in
code space, while a (int * @code) would be a pointer in code space
to an int (presumably in data space).

The idea should be extendable to more address spaces (eg. if 
there was an I/O space), and possibly also to segmented architectures.

Here's a somewhat preliminary (but buildable and working) patch:
2001-09-28  Michael Snyder  <msnyder@redhat.com>
	Add address space identifiers to expression language for types.
	* c-exp.y (space_identifier, cv_with_space_id, 
	const_or_volatile_or_space_identifier_noopt, 
	const_or_volatile_or_space_identifier): New terminals.
	(ptype): Accept const_or_volatile_or_space_identifier.
	(typebase): Accept const_or_volatile_or_space_identifier.
	* c-typeprint.c (c_type_print_cv_qualifier): Rename to
	c_type_print_modifier.  Handle address space modified types.
	* gdbtypes.h (TYPE_FLAG_CODE_SPACE, TYPE_FLAG_DATA_SPACE):
	New type flags.
	(struct type): Add new field as_type for addr-space qualified types.
	* gdbtypes.c (alloc_type): Initialize new field 'as_type'.
	(address_space_name_to_int): New function.
	(address_space_int_to_name): New function.
	(make_type_with_address_space): New function.
	(make_cv_type): Handle as_type field of new struct type object.
	* parse.c (check_type_stack_depth): New function.
	(push_type_address_space): New function.
	(follow_types): Handle types with address-space qualifier.
	* parser-defs.h (enum type_pieces): Add enum tp_space_identifier.

Index: c-exp.y
===================================================================
RCS file: /cvs/src/src/gdb/c-exp.y,v
retrieving revision 1.6
diff -c -3 -p -r1.6 c-exp.y
*** c-exp.y	2001/09/27 21:16:43	1.6
--- c-exp.y	2001/09/28 19:40:34
*************** variable:	name_not_typename
*** 718,741 ****
  			}
  	;
  
! 
! ptype	:	typebase
! 	|	ptype const_or_volatile abs_decl const_or_volatile
! 		{ $$ = follow_types ($1); }
  	;
! const_and_volatile: 	CONST_KEYWORD VOLATILE_KEYWORD
! 	| 		VOLATILE_KEYWORD CONST_KEYWORD
  	;
! const_or_volatile_noopt:  	const_and_volatile 
! 			{ push_type (tp_const); push_type (tp_volatile);}
! 	| 		CONST_KEYWORD
! 			{ push_type (tp_const);}
! 	| 		VOLATILE_KEYWORD
! 			{ push_type (tp_volatile); }
  	;
! const_or_volatile: const_or_volatile_noopt
! 	| 
  	;
  abs_decl:	'*'
  			{ push_type (tp_pointer); $$ = 0; }
  	|	'*' abs_decl
--- 718,741 ----
  			}
  	;
  
! space_identifier : '@' NAME
! 		{ push_type_address_space (copy_name ($2.stoken)); 
! 		  push_type (tp_space_identifier);
! 		}
  	;
! const_or_volatile: const_or_volatile_noopt
! 	|
  	;
! cv_with_space_id : const_or_volatile space_identifier const_or_volatile
  	;
! const_or_volatile_or_space_identifier_noopt: cv_with_space_id
! 	| const_or_volatile_noopt 
! 	;
! const_or_volatile_or_space_identifier: 
! 		const_or_volatile_or_space_identifier_noopt
! 	|
  	;
+ 
  abs_decl:	'*'
  			{ push_type (tp_pointer); $$ = 0; }
  	|	'*' abs_decl
*************** typebase  /* Implements (approximately):
*** 852,859 ****
  			{ $$ = lookup_template_type(copy_name($2), $4,
  						    expression_context_block);
  			}
! 	| const_or_volatile_noopt typebase { $$ = follow_types ($2); }
! 	| typebase const_or_volatile_noopt { $$ = follow_types ($1); }
  	;
  
  typename:	TYPENAME
--- 852,861 ----
  			{ $$ = lookup_template_type(copy_name($2), $4,
  						    expression_context_block);
  			}
! 	| const_or_volatile_or_space_identifier_noopt typebase 
! 			{ $$ = follow_types ($2); }
! 	| typebase const_or_volatile_or_space_identifier_noopt 
! 			{ $$ = follow_types ($1); }
  	;
  
  typename:	TYPENAME
*************** nonempty_typelist
*** 889,894 ****
--- 891,910 ----
  		  $$[$<ivec>$[0]] = $3;
  		}
  	;
+ ptype	:	typebase
+ 	|	ptype const_or_volatile_or_space_identifier abs_decl const_or_volatile_or_space_identifier
+ 		{ $$ = follow_types ($1); }
+ 	;
+ const_and_volatile: 	CONST_KEYWORD VOLATILE_KEYWORD
+ 	| 		VOLATILE_KEYWORD CONST_KEYWORD
+ 	;
+ const_or_volatile_noopt:  	const_and_volatile 
+ 			{ push_type (tp_const); push_type (tp_volatile); }
+ 	| 		CONST_KEYWORD
+ 			{ push_type (tp_const); }
+ 	| 		VOLATILE_KEYWORD
+ 			{ push_type (tp_volatile); }
+ 	;
  
  name	:	NAME { $$ = $1.stoken; }
  	|	BLOCKNAME { $$ = $1.stoken; }
*************** yylex ()
*** 1683,1689 ****
--- 1699,1707 ----
  	  return TYPENAME;
          }
      if ((yylval.tsym.type = lookup_primitive_typename (tmp)) != 0)
+       {
  	return TYPENAME;
+       }
  
      /* Input names that aren't symbols but ARE valid hex numbers,
         when the input radix permits them, can be names or numbers
*************** yyerror (msg)
*** 1715,1717 ****
--- 1733,1736 ----
  {
    error ("A %s in expression, near `%s'.", (msg ? msg : "error"), lexptr);
  }
+ 
Index: c-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-typeprint.c,v
retrieving revision 1.11
diff -c -3 -p -r1.11 c-typeprint.c
*** c-typeprint.c	2001/04/27 00:19:09	1.11
--- c-typeprint.c	2001/09/28 19:40:34
*************** static void cp_type_print_derivation_inf
*** 52,59 ****
  void c_type_print_varspec_prefix (struct type *, struct ui_file *, int,
  				  int);
  
! static void c_type_print_cv_qualifier (struct type *, struct ui_file *,
! 				       int, int);
  \f
  
  
--- 52,60 ----
  void c_type_print_varspec_prefix (struct type *, struct ui_file *, int,
  				  int);
  
! /* Print "const", "volatile", or address space modifiers. */
! static void c_type_print_modifier (struct type *, struct ui_file *,
! 				   int, int);
  \f
  
  
*************** c_type_print_varspec_prefix (struct type
*** 211,217 ****
      case TYPE_CODE_PTR:
        c_type_print_varspec_prefix (TYPE_TARGET_TYPE (type), stream, 0, 1);
        fprintf_filtered (stream, "*");
!       c_type_print_cv_qualifier (type, stream, 1, 0);
        break;
  
      case TYPE_CODE_MEMBER:
--- 212,218 ----
      case TYPE_CODE_PTR:
        c_type_print_varspec_prefix (TYPE_TARGET_TYPE (type), stream, 0, 1);
        fprintf_filtered (stream, "*");
!       c_type_print_modifier (type, stream, 1, 0);
        break;
  
      case TYPE_CODE_MEMBER:
*************** c_type_print_varspec_prefix (struct type
*** 242,248 ****
      case TYPE_CODE_REF:
        c_type_print_varspec_prefix (TYPE_TARGET_TYPE (type), stream, 0, 1);
        fprintf_filtered (stream, "&");
!       c_type_print_cv_qualifier (type, stream, 1, 0);
        break;
  
      case TYPE_CODE_FUNC:
--- 243,249 ----
      case TYPE_CODE_REF:
        c_type_print_varspec_prefix (TYPE_TARGET_TYPE (type), stream, 0, 1);
        fprintf_filtered (stream, "&");
!       c_type_print_modifier (type, stream, 1, 0);
        break;
  
      case TYPE_CODE_FUNC:
*************** c_type_print_varspec_prefix (struct type
*** 289,298 ****
     NEED_SPACE = 1 indicates an initial white space is needed */
  
  static void
! c_type_print_cv_qualifier (struct type *type, struct ui_file *stream,
! 			   int need_pre_space, int need_post_space)
  {
!   int flag = 0;
  
    /* We don't print `const' qualifiers for references --- since all
       operators affect the thing referenced, not the reference itself,
--- 290,300 ----
     NEED_SPACE = 1 indicates an initial white space is needed */
  
  static void
! c_type_print_modifier (struct type *type, struct ui_file *stream,
! 		       int need_pre_space, int need_post_space)
  {
!   int did_print_modifier = 0;
!   char *address_space_id;
  
    /* We don't print `const' qualifiers for references --- since all
       operators affect the thing referenced, not the reference itself,
*************** c_type_print_cv_qualifier (struct type *
*** 303,326 ****
        if (need_pre_space)
  	fprintf_filtered (stream, " ");
        fprintf_filtered (stream, "const");
!       flag = 1;
      }
  
    if (TYPE_VOLATILE (type))
      {
!       if (flag || need_pre_space)
  	fprintf_filtered (stream, " ");
        fprintf_filtered (stream, "volatile");
!       flag = 1;
      }
  
!   if (flag && need_post_space)
      fprintf_filtered (stream, " ");
  }
  
- 
- 
- 
  static void
  c_type_print_args (struct type *type, struct ui_file *stream)
  {
--- 305,334 ----
        if (need_pre_space)
  	fprintf_filtered (stream, " ");
        fprintf_filtered (stream, "const");
!       did_print_modifier = 1;
      }
  
    if (TYPE_VOLATILE (type))
      {
!       if (did_print_modifier || need_pre_space)
  	fprintf_filtered (stream, " ");
        fprintf_filtered (stream, "volatile");
!       did_print_modifier = 1;
      }
  
!   address_space_id = address_space_int_to_name (TYPE_FLAGS (type));
!   if (address_space_id)
!     {
!       if (did_print_modifier || need_pre_space)
! 	fprintf_filtered (stream, " ");
!       fprintf_filtered (stream, "@%s", address_space_id);
!       did_print_modifier = 1;
!     }
! 
!   if (did_print_modifier && need_post_space)
      fprintf_filtered (stream, " ");
  }
  
  static void
  c_type_print_args (struct type *type, struct ui_file *stream)
  {
*************** c_type_print_base (struct type *type, st
*** 655,661 ****
    if (show <= 0
        && TYPE_NAME (type) != NULL)
      {
!       c_type_print_cv_qualifier (type, stream, 0, 1);
        fputs_filtered (TYPE_NAME (type), stream);
        return;
      }
--- 663,669 ----
    if (show <= 0
        && TYPE_NAME (type) != NULL)
      {
!       c_type_print_modifier (type, stream, 0, 1);
        fputs_filtered (TYPE_NAME (type), stream);
        return;
      }
*************** c_type_print_base (struct type *type, st
*** 675,681 ****
        break;
  
      case TYPE_CODE_STRUCT:
!       c_type_print_cv_qualifier (type, stream, 0, 1);
        /* Note TYPE_CODE_STRUCT and TYPE_CODE_CLASS have the same value,
         * so we use another means for distinguishing them.
         */
--- 683,689 ----
        break;
  
      case TYPE_CODE_STRUCT:
!       c_type_print_modifier (type, stream, 0, 1);
        /* Note TYPE_CODE_STRUCT and TYPE_CODE_CLASS have the same value,
         * so we use another means for distinguishing them.
         */
*************** c_type_print_base (struct type *type, st
*** 708,714 ****
        goto struct_union;
  
      case TYPE_CODE_UNION:
!       c_type_print_cv_qualifier (type, stream, 0, 1);
        fprintf_filtered (stream, "union ");
  
      struct_union:
--- 716,722 ----
        goto struct_union;
  
      case TYPE_CODE_UNION:
!       c_type_print_modifier (type, stream, 0, 1);
        fprintf_filtered (stream, "union ");
  
      struct_union:
*************** c_type_print_base (struct type *type, st
*** 1023,1029 ****
        break;
  
      case TYPE_CODE_ENUM:
!       c_type_print_cv_qualifier (type, stream, 0, 1);
        /* HP C supports sized enums */
        if (hp_som_som_object_present)
  	switch (TYPE_LENGTH (type))
--- 1031,1037 ----
        break;
  
      case TYPE_CODE_ENUM:
!       c_type_print_modifier (type, stream, 0, 1);
        /* HP C supports sized enums */
        if (hp_som_som_object_present)
  	switch (TYPE_LENGTH (type))
*************** c_type_print_base (struct type *type, st
*** 1104,1110 ****
           template <class T1, class T2> class "
           and then merges with the struct/union/class code to
           print the rest of the definition. */
!       c_type_print_cv_qualifier (type, stream, 0, 1);
        fprintf_filtered (stream, "template <");
        for (i = 0; i < TYPE_NTEMPLATE_ARGS (type); i++)
  	{
--- 1112,1118 ----
           template <class T1, class T2> class "
           and then merges with the struct/union/class code to
           print the rest of the definition. */
!       c_type_print_modifier (type, stream, 0, 1);
        fprintf_filtered (stream, "template <");
        for (i = 0; i < TYPE_NTEMPLATE_ARGS (type); i++)
  	{
*************** c_type_print_base (struct type *type, st
*** 1139,1145 ****
           is no type name, then complain. */
        if (TYPE_NAME (type) != NULL)
  	{
! 	  c_type_print_cv_qualifier (type, stream, 0, 1);
  	  fputs_filtered (TYPE_NAME (type), stream);
  	}
        else
--- 1147,1153 ----
           is no type name, then complain. */
        if (TYPE_NAME (type) != NULL)
  	{
! 	  c_type_print_modifier (type, stream, 0, 1);
  	  fputs_filtered (TYPE_NAME (type), stream);
  	}
        else
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.25
diff -c -3 -p -r1.25 gdbtypes.c
*** gdbtypes.c	2001/08/24 04:46:43	1.25
--- gdbtypes.c	2001/09/28 19:40:35
*************** alloc_type (struct objfile *objfile)
*** 144,149 ****
--- 144,150 ----
    TYPE_OBJFILE (type) = objfile;
    TYPE_VPTR_FIELDNO (type) = -1;
    TYPE_CV_TYPE (type) = type;	/* chain back to itself */
+   TYPE_AS_TYPE (type) = type;	/* ditto */
  
    return (type);
  }
*************** lookup_function_type (struct type *type)
*** 321,327 ****
--- 322,396 ----
    return make_function_type (type, (struct type **) 0);
  }
  
+ /* Identify address space identifier by name --
+    return the integer flag defined in gdbtypes.h.  */
+ extern int
+ address_space_name_to_int (char *space_identifier)
+ {
+   /* Check for known address space delimiters. */
+   if (!strcmp (space_identifier, "code"))
+     return TYPE_FLAG_CODE_SPACE;
+   else if (!strcmp (space_identifier, "data"))
+     return TYPE_FLAG_DATA_SPACE;
+   else
+     error ("Unknown address space specifier: \"%s\"", space_identifier);
+ }
+ 
+ /* Identify address space identifier by integer flag as defined in 
+    gdbtypes.h -- return the string version of the adress space name. */
+ 
+ extern char *
+ address_space_int_to_name (int space_flag)
+ {
+   if (space_flag & TYPE_FLAG_CODE_SPACE)
+     return "code";
+   else if (space_flag & TYPE_FLAG_DATA_SPACE)
+     return "data";
+   else
+     return NULL;
+ }
+ 
+ /* Make an address-space-delimited variant of a type -- a type that
+    is identical to the one supplied except that it has an address
+    space attribute attached to it (such as "code" or "data").
+ 
+    This is for Harvard architectures. */
+ 
+ struct type *
+ make_type_with_address_space (struct type *type, int space_flag)
+ {
+   struct type *ntype;
  
+   ntype = type;
+   do {
+       if ((ntype->flags & space_flag) != 0)
+ 	return ntype;
+       ntype = TYPE_AS_TYPE (ntype);
+   } while (ntype != type);
+ 
+   /* Create a new, duplicate type. */
+   ntype = alloc_type (TYPE_OBJFILE (type));
+   /* Copy original type. */
+   memcpy ((char *) ntype, (char *) type, sizeof (struct type));
+ 
+   /* Pointers or references to the original type are not relevant to
+      the new type; but if the original type is a pointer, the new type
+      points to the same thing (so TYPE_TARGET_TYPE remains
+      unchanged). */
+   TYPE_POINTER_TYPE (ntype) = (struct type *) 0;
+   TYPE_REFERENCE_TYPE (ntype) = (struct type *) 0;
+   TYPE_CV_TYPE (ntype) = ntype;
+ 
+   /* Chain the new address-space-specific type to the old type. */
+   ntype->as_type = type->as_type;
+   type->as_type = ntype;
+ 
+   /* Now set the address-space flag, and return the new type. */
+   ntype->flags |= space_flag;
+   return ntype;
+ }
+ 
+ 
  /* Make a "c-v" variant of a type -- a type that is identical to the
     one supplied except that it may have const or volatile attributes
     CNST is a flag for setting the const attribute
*************** make_cv_type (int cnst, int voltl, struc
*** 378,383 ****
--- 447,453 ----
    /* But zero out fields that shouldn't be copied */
    TYPE_POINTER_TYPE (ntype) = (struct type *) 0;	/* Need new pointer kind */
    TYPE_REFERENCE_TYPE (ntype) = (struct type *) 0;	/* Need new referene kind */
+   TYPE_AS_TYPE (ntype) = ntype;		/* Need new address-space kind. */
    /* Note: TYPE_TARGET_TYPE can be left as is */
  
    /* Set flags appropriately */
*************** make_cv_type (int cnst, int voltl, struc
*** 398,406 ****
    return ntype;
  }
  
- 
- 
- 
  /* Implement direct support for MEMBER_TYPE in GNU C++.
     May need to construct such a type if this is the first use.
     The TYPE is the type of the member.  The DOMAIN is the type
--- 468,473 ----
*************** build_gdbtypes (void)
*** 2842,2847 ****
--- 2909,2915 ----
      init_type (TYPE_CODE_INT, TARGET_SHORT_BIT / TARGET_CHAR_BIT,
  	       0,
  	       "short", (struct objfile *) NULL);
+ 
    builtin_type_unsigned_short =
      init_type (TYPE_CODE_INT, TARGET_SHORT_BIT / TARGET_CHAR_BIT,
  	       TYPE_FLAG_UNSIGNED,
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.16
diff -c -3 -p -r1.16 gdbtypes.h
*** gdbtypes.h	2001/09/08 10:16:57	1.16
--- gdbtypes.h	2001/09/28 19:40:35
*************** enum type_code
*** 206,212 ****
--- 206,234 ----
  
  #define TYPE_FLAG_INCOMPLETE (1 << 8)
  
+ /* Instruction-space delimited type.  This is for Harvard architectures
+    which have separate instruction and data address spaces (and perhaps
+    others).
+ 
+    GDB usually defines a flat address space that is a superset of the
+    architecture's two (or more) address spaces, but this is an extension
+    of the architecture's model.
+ 
+    If TYPE_FLAG_INST is set, an object of the corresponding type
+    resides in instruction memory, even if its address (in the extended
+    flat address space) does not reflect this.
+ 
+    Similarly, if TYPE_FLAG_DATA is set, then an object of the 
+    corresponding type resides in the data memory space, even if
+    this is not indicated by its (flat address space) address.
  
+    If neither flag is set, the default space for functions / methods
+    is instruction space, and for data objects is data memory.  */
+ 
+ #define TYPE_FLAG_CODE_SPACE (1 << 9)
+ #define TYPE_FLAG_DATA_SPACE (1 << 10)
+ 
+ 
  struct type
    {
  
*************** struct type
*** 310,315 ****
--- 332,343 ----
         are chained together in a ring. */
      struct type *cv_type;
  
+     /* Address-space delimited variant chain.  This points to a type
+        that differs from this one only in an address-space qualifier
+        attribute.  The otherwise-identical address-space delimited 
+        types are chained together in a ring. */
+     struct type *as_type;
+ 
      /* Flags about this type.  */
  
      int flags;
*************** extern void allocate_cplus_struct_type (
*** 689,694 ****
--- 717,723 ----
  #define TYPE_POINTER_TYPE(thistype) (thistype)->pointer_type
  #define TYPE_REFERENCE_TYPE(thistype) (thistype)->reference_type
  #define TYPE_CV_TYPE(thistype) (thistype)->cv_type
+ #define TYPE_AS_TYPE(thistype) (thistype)->as_type
  /* Note that if thistype is a TYPEDEF type, you have to call check_typedef.
     But check_typedef does set the TYPE_LENGTH of the TYPEDEF type,
     so you only have to call check_typedef once.  Since allocate_value
*************** extern struct type *lookup_reference_typ
*** 1005,1010 ****
--- 1034,1046 ----
  extern struct type *make_reference_type (struct type *, struct type **);
  
  extern struct type *make_cv_type (int, int, struct type *, struct type **);
+ 
+ extern int address_space_name_to_int (char *);
+ 
+ extern char *address_space_int_to_name (int);
+ 
+ extern struct type *make_type_with_address_space (struct type *type, 
+ 						  int space_identifier);
  
  extern struct type *lookup_member_type (struct type *, struct type *);
  
Index: parse.c
===================================================================
RCS file: /cvs/src/src/gdb/parse.c,v
retrieving revision 1.16
diff -c -3 -p -r1.16 parse.c
*** parse.c	2001/09/27 22:39:05	1.16
--- parse.c	2001/09/28 19:40:35
*************** parse_expression (char *string)
*** 1208,1215 ****
  /* Stuff for maintaining a stack of types.  Currently just used by C, but
     probably useful for any language which declares its types "backwards".  */
  
! void
! push_type (enum type_pieces tp)
  {
    if (type_stack_depth == type_stack_size)
      {
--- 1208,1215 ----
  /* Stuff for maintaining a stack of types.  Currently just used by C, but
     probably useful for any language which declares its types "backwards".  */
  
! static void
! check_type_stack_depth (void)
  {
    if (type_stack_depth == type_stack_size)
      {
*************** push_type (enum type_pieces tp)
*** 1217,1237 ****
        type_stack = (union type_stack_elt *)
  	xrealloc ((char *) type_stack, type_stack_size * sizeof (*type_stack));
      }
    type_stack[type_stack_depth++].piece = tp;
  }
  
  void
  push_type_int (int n)
  {
!   if (type_stack_depth == type_stack_size)
!     {
!       type_stack_size *= 2;
!       type_stack = (union type_stack_elt *)
! 	xrealloc ((char *) type_stack, type_stack_size * sizeof (*type_stack));
!     }
    type_stack[type_stack_depth++].int_val = n;
  }
  
  enum type_pieces
  pop_type (void)
  {
--- 1217,1244 ----
        type_stack = (union type_stack_elt *)
  	xrealloc ((char *) type_stack, type_stack_size * sizeof (*type_stack));
      }
+ }
+ 
+ void
+ push_type (enum type_pieces tp)
+ {
+   check_type_stack_depth ();
    type_stack[type_stack_depth++].piece = tp;
  }
  
  void
  push_type_int (int n)
  {
!   check_type_stack_depth ();
    type_stack[type_stack_depth++].int_val = n;
  }
  
+ void
+ push_type_address_space (char *string)
+ {
+   push_type_int (address_space_name_to_int (string));
+ }
+ 
  enum type_pieces
  pop_type (void)
  {
*************** follow_types (struct type *follow_type)
*** 1257,1262 ****
--- 1264,1270 ----
    int done = 0;
    int make_const = 0;
    int make_volatile = 0;
+   int make_addr_space = 0;
    int array_size;
    struct type *range_type;
  
*************** follow_types (struct type *follow_type)
*** 1273,1278 ****
--- 1281,1291 ----
  	  follow_type = make_cv_type (TYPE_CONST (follow_type), 
  				      make_volatile, 
  				      follow_type, 0);
+ 	if (make_addr_space)
+ 	  follow_type = make_type_with_address_space (follow_type, 
+ 						      make_addr_space);
+ 	make_const = make_volatile = 0;
+ 	make_addr_space = 0;
  	break;
        case tp_const:
  	make_const = 1;
*************** follow_types (struct type *follow_type)
*** 1280,1285 ****
--- 1293,1301 ----
        case tp_volatile:
  	make_volatile = 1;
  	break;
+       case tp_space_identifier:
+ 	make_addr_space = pop_type_int ();
+ 	break;
        case tp_pointer:
  	follow_type = lookup_pointer_type (follow_type);
  	if (make_const)
*************** follow_types (struct type *follow_type)
*** 1290,1304 ****
  	  follow_type = make_cv_type (TYPE_CONST (follow_type), 
  				      make_volatile, 
  				      follow_type, 0);
  	make_const = make_volatile = 0;
  	break;
        case tp_reference:
  	follow_type = lookup_reference_type (follow_type);
  	if (make_const)
! 	  follow_type = make_cv_type (make_const, TYPE_VOLATILE (follow_type), follow_type, 0);
  	if (make_volatile)
! 	  follow_type = make_cv_type (TYPE_CONST (follow_type), make_volatile, follow_type, 0);
  	make_const = make_volatile = 0;
  	break;
        case tp_array:
  	array_size = pop_type_int ();
--- 1306,1332 ----
  	  follow_type = make_cv_type (TYPE_CONST (follow_type), 
  				      make_volatile, 
  				      follow_type, 0);
+ 	if (make_addr_space)
+ 	  follow_type = make_type_with_address_space (follow_type, 
+ 						      make_addr_space);
  	make_const = make_volatile = 0;
+ 	make_addr_space = 0;
  	break;
        case tp_reference:
  	follow_type = lookup_reference_type (follow_type);
  	if (make_const)
! 	  follow_type = make_cv_type (make_const, 
! 				      TYPE_VOLATILE (follow_type), 
! 				      follow_type, 0);
  	if (make_volatile)
! 	  follow_type = make_cv_type (TYPE_CONST (follow_type), 
! 				      make_volatile, 
! 				      follow_type, 0);
! 	if (make_addr_space)
! 	  follow_type = make_type_with_address_space (follow_type, 
! 						      make_addr_space);
  	make_const = make_volatile = 0;
+ 	make_addr_space = 0;
  	break;
        case tp_array:
  	array_size = pop_type_int ();
Index: parser-defs.h
===================================================================
RCS file: /cvs/src/src/gdb/parser-defs.h,v
retrieving revision 1.5
diff -c -3 -p -r1.5 parser-defs.h
*** parser-defs.h	2001/09/27 22:39:05	1.5
--- parser-defs.h	2001/09/28 19:40:36
*************** enum type_pieces
*** 90,96 ****
      tp_array, 
      tp_function, 
      tp_const, 
!     tp_volatile
    };
  /* The stack can contain either an enum type_pieces or an int.  */
  union type_stack_elt
--- 90,97 ----
      tp_array, 
      tp_function, 
      tp_const, 
!     tp_volatile, 
!     tp_space_identifier
    };
  /* The stack can contain either an enum type_pieces or an int.  */
  union type_stack_elt
*************** extern char *copy_name (struct stoken);
*** 140,145 ****
--- 141,148 ----
  extern void push_type (enum type_pieces);
  
  extern void push_type_int (int);
+ 
+ extern void push_type_address_space (char *);
  
  extern enum type_pieces pop_type (void);
  
From ac131313@cygnus.com Fri Sep 28 13:34:00 2001
From: Andrew Cagney <ac131313@cygnus.com>
To: Daniel Jacobowitz <drow@mvista.com>, fnasser@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa/testsuite/mi] Recognize a few incorrect outputs
Date: Fri, 28 Sep 2001 13:34:00 -0000
Message-id: <3BB4DEBB.1020906@cygnus.com>
References: <20010928151616.A14106@nevyn.them.org>
X-SW-Source: 2001-09/msg00433.html
Content-length: 985

> <gripe>
> A lot of GDB tests seem to be written with only pass and timeout
> alternatives, or only with overly-specialized fails.  The hypocrite-alert
> readers of this message will note that I'm guilty of the same thing; this is
> Just Enough to make them catch a few errors I could think of, not enough to
> recognize completely wrong output.  Someday, someone more motivated than I
> should clean this up.
> </gripe>

For the MI, this is a pretty obvious fix.  I've been doing the same 
thing my self (when I noticed it).  One suggestion, can you make that 
fail expression less strict so that it picks.  Something like:

	<correct-output> (gdb) <more-output> (gdb)
		pass

	.* (gdb) .* (gdb)
		fail

	timeout
		fail

alternatively (hmm, better?), keep the expression as you have it but add 
a comment in paren vis:

	fail "continue to incr_a (compiler bug info is wrong)"

Fernando,

Given the compiler debug info is ``wrong'' would this even qualify for 
as an xfail?

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> + extern char *
> + address_space_int_to_name (int space_flag)
> + {
> +   if (space_flag & TYPE_FLAG_CODE_SPACE)
> +     return "code";
> +   else if (space_flag & TYPE_FLAG_DATA_SPACE)
> +     return "data";
> +   else
> +     return NULL;
> + }
> + 

Some thoughts on the internals.

Should these spaces be flags or an enumeration?  I don't think being 
able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks 
also puts a limitation on the number of spaces.

Should a flag  always be set (if not specified explicitly).  For 
instance, a ``(*)()'' which implies the code space explicitly setting it 
as such?  That will make some of the pointer to/from address code easier 
- just check the space - no need to test for func or method or ....

I suspect that this is going to slowly affect other parts. At present 
there is a singe TARGET_PTR_BIT.  Given different address spaces can 
have different sizes, that macro will be replaced by a more generic 
(target_space_ptr_bit (space).

As you note, for the moment text/data are hardwired / pre-defined 
Eventually the target architecture will want an oportunity to define 
other spaces.  That can follow.

Andrew

PS: I keep reading type_as_type as type as type :-)

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > + extern char *
> > + address_space_int_to_name (int space_flag)
> > + {
> > +   if (space_flag & TYPE_FLAG_CODE_SPACE)
> > +     return "code";
> > +   else if (space_flag & TYPE_FLAG_DATA_SPACE)
> > +     return "data";
> > +   else
> > +     return NULL;
> > + }
> > +
> 
> Some thoughts on the internals.
> 
> Should these spaces be flags or an enumeration?  I don't think being
> able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks
> also puts a limitation on the number of spaces.

Yes, but it's a generous limitation (there are 20 more bits available).
I'll go either way -- the trade-off is that if we don't use the "flags"
field, we have to add a new field to the (struct type) data structure.

> Should a flag  always be set (if not specified explicitly).  For
> instance, a ``(*)()'' which implies the code space explicitly setting it
> as such?  That will make some of the pointer to/from address code easier
> - just check the space - no need to test for func or method or ....

Maybe, but that can be done as a follow-on extension to what I've done.
The change I've submitted works now, it doesn't require this addition
(so we don't have to decide now).

I should explain -- without this change, the way GDB currently does this
is to look at the types of expressions, and divide them into two categories:

  1) functions and things pointed to by function pointers, and
  2) everything else (which basically includes data-like objects
     (scalars, structs, arrays of data-like objects...)

The first are always treated as living in code-space, and
the second are always treated as living in data-space. 
The extension that I'm submitting merely gives the user
the ability to override that assumption (eg. to look at
data objects that have been located in code space).
If an expression is _not_ cast using the "@code" or "@data"
modifiers, then the original defaults still apply.

> I suspect that this is going to slowly affect other parts. At present
> there is a singe TARGET_PTR_BIT.  Given different address spaces can
> have different sizes, that macro will be replaced by a more generic
> (target_space_ptr_bit (space).
> 
> As you note, for the moment text/data are hardwired / pre-defined
> Eventually the target architecture will want an oportunity to define
> other spaces.  That can follow.

Yep.  Many more changes are likely to follow, step by step.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Daniel Jacobowitz]

On Wed, Oct 03, 2001 at 10:40:32AM -0700, Michael Snyder wrote:
> Andrew Cagney wrote:
> > 
> > > + extern char *
> > > + address_space_int_to_name (int space_flag)
> > > + {
> > > +   if (space_flag & TYPE_FLAG_CODE_SPACE)
> > > +     return "code";
> > > +   else if (space_flag & TYPE_FLAG_DATA_SPACE)
> > > +     return "data";
> > > +   else
> > > +     return NULL;
> > > + }
> > > +
> > 
> > Some thoughts on the internals.
> > 
> > Should these spaces be flags or an enumeration?  I don't think being
> > able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks
> > also puts a limitation on the number of spaces.
> 
> Yes, but it's a generous limitation (there are 20 more bits available).
> I'll go either way -- the trade-off is that if we don't use the "flags"
> field, we have to add a new field to the (struct type) data structure.

May I suggest:
	if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)

I'd prefer to preserve the knowledge that an object is in only one
space.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Wed, Oct 03, 2001 at 10:40:32AM -0700, Michael Snyder wrote:
> > Andrew Cagney wrote:
> > >
> > > > + extern char *
> > > > + address_space_int_to_name (int space_flag)
> > > > + {
> > > > +   if (space_flag & TYPE_FLAG_CODE_SPACE)
> > > > +     return "code";
> > > > +   else if (space_flag & TYPE_FLAG_DATA_SPACE)
> > > > +     return "data";
> > > > +   else
> > > > +     return NULL;
> > > > + }
> > > > +
> > >
> > > Some thoughts on the internals.
> > >
> > > Should these spaces be flags or an enumeration?  I don't think being
> > > able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks
> > > also puts a limitation on the number of spaces.
> >
> > Yes, but it's a generous limitation (there are 20 more bits available).
> > I'll go either way -- the trade-off is that if we don't use the "flags"
> > field, we have to add a new field to the (struct type) data structure.
> 
> May I suggest:
>         if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)
> 
> I'd prefer to preserve the knowledge that an object is in only one
> space.

Sure, good suggestion.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>  May I suggest:
>> if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)
>> 
>> I'd prefer to preserve the knowledge that an object is in only one
>> space.
> 
> 
> Sure, good suggestion.


Remember, the number of spaces is determined by the target architecture. 
  You can probably reserve a fixed set but it may eventually overflow.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> >  May I suggest:
> >> if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)
> >>
> >> I'd prefer to preserve the knowledge that an object is in only one
> >> space.
> >
> >
> > Sure, good suggestion.
> 
> Remember, the number of spaces is determined by the target architecture.
>   You can probably reserve a fixed set but it may eventually overflow.

And as you observed (I think), it would eventually be desireable 
to give the target arch the ability to define the spaces.
My hardwiring of "code" and "data" is just an initial step.
When we make it extendable, the internal implementation may be
entirely different, and the artificial limit on the number of
address spaces may go away.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Andrew Cagney wrote:
> 
>> 
> 
>> > May I suggest:
> 
>> >> if ((space_flag & TYPE_FLAG_SPACE_MASK) == TYPE_FLAG_CODE_SPACE)
>> >>
>> >> I'd prefer to preserve the knowledge that an object is in only one
>> >> space.
> 
>> >
>> >
>> > Sure, good suggestion.
> 
>> 
>> Remember, the number of spaces is determined by the target architecture.
>> You can probably reserve a fixed set but it may eventually overflow.
> 
> 
> And as you observed (I think), it would eventually be desireable 
> to give the target arch the ability to define the spaces.
> My hardwiring of "code" and "data" is just an initial step.
> When we make it extendable, the internal implementation may be
> entirely different, and the artificial limit on the number of
> address spaces may go away.


Ah, define code, data and I/O bits and then leave the problem of 
changing that to an enum / integer / struct ...  to the person that has 
all the address spaces.

Probably a good choice,

	Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Michael Snyder <msnyder@cygnus.com> writes:
> > Should these spaces be flags or an enumeration?  I don't think being
> > able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks
> > also puts a limitation on the number of spaces.
> 
> Yes, but it's a generous limitation (there are 20 more bits available).
> I'll go either way -- the trade-off is that if we don't use the "flags"
> field, we have to add a new field to the (struct type) data
> structure.

(This is a suggested enhancement to Michael's patch; I think it's a
step forward as is.)

Instead of using bits, what if we added a new `const char *' field to
`struct type'?  Its value would be a string indicating the name of the
space qualifier applied to the type, or zero indicating the default.
The set of permitted space names would be determined by the
architecture, following some basic conventions (like `data' and
`code').  There would be a gdbarch method like this:

- int gdbarch_valid_addr_space_name_p (struct gdbarch *A, const char *NAME);
  Return non-zero if NAME is a valid name of an address space
  for architecture A.

The parser would recognize `@ IDENTIFIER' as a space qualifier, call
gdbarch_valid_addr_space_name_p to check it, and drop the value into
the type it creates if so.

The type printer would simply printf ("@%s", type->space); when printing.

There would be a core function:

- const char *type_default_addr_space (struct type *T);
  Return "code" if T is a pointer to function or method; return "data"
  otherwise.

The POINTER_TO_ADDRESS and ADDRESS_TO_POINTER methods, which are the
ones who actually *use* this info, receive the type object already,
and can check the space as appropriate.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> 
> (This is a suggested enhancement to Michael's patch; I think it's a
> step forward as is.)

Jim, no one, so far, has disputed this.

> Instead of using bits, what if we added a new `const char *' field to
> `struct type'?  Its value would be a string indicating the name of the
> space qualifier applied to the type, or zero indicating the default.
> The set of permitted space names would be determined by the
> architecture, following some basic conventions (like `data' and
> `code').  There would be a gdbarch method like this:

What are the rules that apply when the user wishes to compare two such 
space strings?  strcmp() or ==?

	Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > (This is a suggested enhancement to Michael's patch; I think it's a
> > step forward as is.)
> 
> Jim, no one, so far, has disputed this.

Oh!  That was not at all clear.  Both Michael and I thought you were
objecting to it.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Jim Blandy wrote:
> 
> Michael Snyder <msnyder@cygnus.com> writes:
> > > Should these spaces be flags or an enumeration?  I don't think being
> > > able to specify space = (CODE | DATA) is meanginful.  Haveing bit masks
> > > also puts a limitation on the number of spaces.
> >
> > Yes, but it's a generous limitation (there are 20 more bits available).
> > I'll go either way -- the trade-off is that if we don't use the "flags"
> > field, we have to add a new field to the (struct type) data
> > structure.
> 
> (This is a suggested enhancement to Michael's patch; I think it's a
> step forward as is.)
> 
> Instead of using bits, what if we added a new `const char *' field to
> `struct type'?  Its value would be a string indicating the name of the
> space qualifier applied to the type, or zero indicating the default.

Just to make sure I understand you, the string you propose is
something like "code", not the fully qualified type eg. "code int *";
right?


> The set of permitted space names would be determined by the
> architecture, following some basic conventions (like `data' and
> `code').  There would be a gdbarch method like this:
> 
> - int gdbarch_valid_addr_space_name_p (struct gdbarch *A, const char *NAME);
>   Return non-zero if NAME is a valid name of an address space
>   for architecture A.
> 
> The parser would recognize `@ IDENTIFIER' as a space qualifier, call
> gdbarch_valid_addr_space_name_p to check it, and drop the value into
> the type it creates if so.
> 
> The type printer would simply printf ("@%s", type->space); when printing.
> 
> There would be a core function:
> 
> - const char *type_default_addr_space (struct type *T);
>   Return "code" if T is a pointer to function or method; return "data"
>   otherwise.
> 
> The POINTER_TO_ADDRESS and ADDRESS_TO_POINTER methods, which are the
> ones who actually *use* this info, receive the type object already,
> and can check the space as appropriate.

OK, the reason I didn't do it like that (and I did consider it) is
  a) it required a new field in the type struct, and
  b) a strcmp takes longer than an integer (flag) test.

However, I agree that this might be a reasonable extension, 
especially once we get ready to let the target architecture
define its own address spaces.  I wanted to get a relatively
simple initial implementation approved before I went overboard
on complexity (it's complex enough as it is).

Michael

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Michael Snyder <msnyder@redhat.com> writes:
> > Instead of using bits, what if we added a new `const char *' field to
> > `struct type'?  Its value would be a string indicating the name of the
> > space qualifier applied to the type, or zero indicating the default.
> 
> Just to make sure I understand you, the string you propose is
> something like "code", not the fully qualified type eg. "code int *";
> right?

Yes.

> > The set of permitted space names would be determined by the
> > architecture, following some basic conventions (like `data' and
> > `code').  There would be a gdbarch method like this:
> > 
> > - int gdbarch_valid_addr_space_name_p (struct gdbarch *A, const char *NAME);
> >   Return non-zero if NAME is a valid name of an address space
> >   for architecture A.
> > 
> > The parser would recognize `@ IDENTIFIER' as a space qualifier, call
> > gdbarch_valid_addr_space_name_p to check it, and drop the value into
> > the type it creates if so.
> > 
> > The type printer would simply printf ("@%s", type->space); when printing.
> > 
> > There would be a core function:
> > 
> > - const char *type_default_addr_space (struct type *T);
> >   Return "code" if T is a pointer to function or method; return "data"
> >   otherwise.
> > 
> > The POINTER_TO_ADDRESS and ADDRESS_TO_POINTER methods, which are the
> > ones who actually *use* this info, receive the type object already,
> > and can check the space as appropriate.
> 
> OK, the reason I didn't do it like that (and I did consider it) is
>   a) it required a new field in the type struct, and
>   b) a strcmp takes longer than an integer (flag) test.
> 
> However, I agree that this might be a reasonable extension, 
> especially once we get ready to let the target architecture
> define its own address spaces.  I wanted to get a relatively
> simple initial implementation approved before I went overboard
> on complexity (it's complex enough as it is).

Okay.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> This is an extension to help with debugging on Harvard architectures
> (machines with two or more address spaces, typically one for 
> instructions and one for data).  The idea here is to provide the user 
> with a mechanism for specifying the address space of a pointer or
> a raw address (eg. to display the contents of code memory as opposed
> to data memory, when the address alone is not enough to differentiate).
> 
> Rather than provide extensions for specific commands such as print
> and examine, it seemed more useful and general to provide an 
> extension to the syntax for type expressions.  Thus we can identify
> a pointer to (say) code address space by using a pointer cast, and
> that expression can be used in any command that accepts an expression.
> 
> 	(gdb) x /xb (@code short *) foo
> 	(gdb) print *(@data char *) 0x1000
> 	(gdb) set *(@code long long *) 0x1000 = 0
> 
> The idea is that the modifiers "@code" and "@data" can be used
> anywhere where it would be legal to use "const" or "volatile".
> I've used the "@" character to remove the new keywords from the
> user name space, but I'm open to discussion on that choice
> ("$" might be another possibility).
> 
> So, for instance, a (@code int *) would be a pointer to an int in
> code space, while a (int * @code) would be a pointer in code space
> to an int (presumably in data space).

The syntax feels long winded - which probably isn't unexpected.  It is 
playing around with a type system.  Shortened / abreviated forms are 
going to be useful.

I know Fche once suggested:

	x/i $code + 100

where $code designates a code base address.  I guess, using the above, 
$code would be syntatic sugar for ``(@code char *) 0'' giving ``(@code 
char *)0 + 100'' for the above.

--

Looking at the output and how it interacts.  I'll give several examples 
and possible outputs:

	(gdb) print (@data char *) 0x1000

	(@data char *) 0x1000
or 
(char *) 0x1000

	(gdb) print ((@code *)()) 0x1000
(I think)

	((@code *)()) 0x1000
or 
((*)()) 0x1000

I think in each case it should display the latter - the ``@code'' 
attribute is redundant information.  Only when the space conflicts with 
the values type should it be displayed.

--

What about expressions.

Consider
	(gdb) print (char *) function

should that return:

	(@data char *) ...
or 
(@code char *) ...





> The idea should be extendable to more address spaces (eg. if 
> there was an I/O space), and possibly also to segmented architectures.
> 
> Here's a somewhat preliminary (but buildable and working) patch:
> 
> 

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> What about expressions.
> 
> Consider
>     (gdb) print (char *) function
> 
> should that return:
> 
>     (@data char *) ...
> or (@code char *) ...

Oops, pressed the wrong button ...

My question here is, should the address space be propogated through a 
type conversion (when it isn't explicitly specified)?

The user might have the expression:

	x/i function

and then enter

	x/w function

Both will examine the same memory location.  The user could then try to 
manipulate that data with:

	print *(int*)function

however, depending on the interpretation of the expression (I don't 
believe ISO C defines the semantics of this) you could end up printing a 
value from a completly different address space.

Would it be better if the cast operator, by default, preserved the 
address space of the pointer being cast?

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Would it be better if the cast operator, by default, preserved the 
> address space of the pointer being cast?

That would get a bit hairy.  If I've got a value of the type:

        (@code int * @code * @code * @code)

--- that is, "a pointer in code space to a pointer in code space to a
pointer in code space to an int in code space" --- and cast it to

        (int **)

(note that I've dropped a layer of pointers here), how far down do we
go?  Does that become a `@code int * @code * @code'?  Or just a `int
* @code *'?  It's a bit weird.

I kind of think that casts should just work the normal way.  People
working on machines with separate address spaces have to think a
little harder --- I don't think we can really conceal that.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> Would it be better if the cast operator, by default, preserved the 
>> address space of the pointer being cast?
> 
> 
> That would get a bit hairy.  If I've got a value of the type:
> 
>         (@code int * @code * @code * @code)
> 
> --- that is, "a pointer in code space to a pointer in code space to a
> pointer in code space to an int in code space" --- and cast it to
> 
>         (int **)
> 
> (note that I've dropped a layer of pointers here), how far down do we
> go?  Does that become a `@code int * @code * @code'?  Or just a `int
> * @code *'?  It's a bit weird.

You don't.

> I kind of think that casts should just work the normal way.  People
> working on machines with separate address spaces have to think a
> little harder --- I don't think we can really conceal that.

Remember we're talking about poerations that potentially cast a code 
pointer to a data or I/O pointer so this can't be described as normal. 
It is definitly way outside the bounds of the C language spec.

Any way, consider the intent of someone entering a sequence like:

	(gdb) x/w foo
	0x0
	(gdb) x/i foo
	nop
	(gdb) print/x *(int*)foo
	0xdeadbeef

vs 
(gdb) print/x *(int*)foo
	0x0

and where should this go:

	(gdb) set *(int*)foo = 0xdeadbeef

This mysterious address switching strikes me as wierd.

	Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Andrew Cagney <ac131313@cygnus.com> writes:
> >
> >> Would it be better if the cast operator, by default, preserved the
> >> address space of the pointer being cast?
> >
> >
> > That would get a bit hairy.  If I've got a value of the type:
> >
> >         (@code int * @code * @code * @code)
> >
> > --- that is, "a pointer in code space to a pointer in code space to a
> > pointer in code space to an int in code space" --- and cast it to
> >
> >         (int **)
> >
> > (note that I've dropped a layer of pointers here), how far down do we
> > go?  Does that become a `@code int * @code * @code'?  Or just a `int
> > * @code *'?  It's a bit weird.
> 
> You don't.
> 
> > I kind of think that casts should just work the normal way.  People
> > working on machines with separate address spaces have to think a
> > little harder --- I don't think we can really conceal that.
> 
> Remember we're talking about poerations that potentially cast a code
> pointer to a data or I/O pointer so this can't be described as normal.
> It is definitly way outside the bounds of the C language spec.
> 
> Any way, consider the intent of someone entering a sequence like:
> 
>         (gdb) x/w foo
>         0x0
>         (gdb) x/i foo
>         nop

Andrew, right now the "x" command has no knowledge about
separate code and data spaces, so both "x/w foo" and "x/i foo" 
will refer to the same address.  Whether that address comes
from code or data space depends entirely on the data type of foo.
If foo is a data-like object (eg. an int or an int pointer)
it will come from data space.  If foo is a function, it will come
from code space.  The purpose of the @code and @data modifiers
is to override this default.

>         (gdb) print/x *(int*)foo
>         0xdeadbeef

An (int *) is by default a data pointer.
A function pointer is by default a code pointer.

> vs
> (gdb) print/x *(int*)foo
>         0x0
> 
> and where should this go:
> 
>         (gdb) set *(int*)foo = 0xdeadbeef

This will go to data space.  Any "normal" data type will default to data 
space (as it already does).  The @code and @data modifiers are for when 
you want to alter the default behavior.

> This mysterious address switching strikes me as wierd.

You are right -- it's wierd.  ;-)

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>> (gdb) print/x *(int*)foo
>> 0xdeadbeef
> 
> 
> An (int *) is by default a data pointer.
> A function pointer is by default a code pointer.

As far as I know, the C language says nothing about the above (assuming 
foo is a function).  It is an implementation defined pointer cast open 
to any interpretation.  All it defines are ``pointer from data to data 
space'' and ``pointer from data to code space''.  It doesn't even define 
foo+4, where foo is a function.

Any way, lets break down the proposal.

--

Firstly it is adding a mechanism that will allow GDB to represent 
pointers to / from / within any address space.

We absolutly need this.  And such a change can probably be dropped right 
in. However check note below.

--

Next we've got the syntax change - an attribute extension.  While querky 
  it doesn't worry me - if I'm understanding it correctly, it is 
possible to add syntatic sugar for common operations (such as references 
to code space) [see other e-mail]. (However do check note below :-)

--

Finally, there are the semantics of the operations.  Here I think we're 
clearly disagreeing.  I'm arguing that an address is an address is an 
address - it always designates the one location - unless explicitly 
converted.  In the proposal it silently moves depending on what was 
done.  The  pointer cast operator is being given certain semantics - I 
think those semantics are not what the user expects.

Per my previous comment, given a function foo.  I'd contend that the 
user is going to expect the expression:

	*(int*)foo

to print an integer at address foo and not at some other data address.

BTW, regarding ``(int *)'' is always ``(@data int *@data)'' that is 
true.  Rember though that the above is really:

	cast ((int*), (@code *@data))

and as far as I know, this operation isn't defined by C?  It is free to 
apply arbitrary transformations that might include:

	(@data int *@data)
or 
(@code int *@data)

Any way, if GDB is going to have an address changes model (I consider 
this user broken) then, at a minimum, it should warn the user that an 
address space change has been applied to their apparently simple address 
expression.

--

``Note below'':


The basic framework attached the segment information to the pointee 
rather than pointer.  Was this an arbitrary decision or based on some 
theoretical framework.

Since the pointee gets the attribute it is possible to construct things 
like:

	(@code struct { @data int i; @io unsigned char *@data c; } *)

was this the intent?  (I suspect it was: having a @data -> @io space 
pointer sitting in code memory, while sick, is still plausable).

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Finally, there are the semantics of the operations.  Here I think we're 
> clearly disagreeing.  I'm arguing that an address is an address is an 
> address - it always designates the one location - unless explicitly 
> converted.  In the proposal it silently moves depending on what was 
> done.  The  pointer cast operator is being given certain semantics - I 
> think those semantics are not what the user expects.

In any C compiler, the expressions `(int *) &main' and `(int (*) ())
&argc' will also silently change the location referred to.  GDB is
simply evaluating the expressions the way the compiler would.

(BTW, these are also GDB's current semantics.  The proposal doesn't
introduce any new inconsistencies.)

What if GDB printed a warning when an operation switched a pointer
from one space to another?

  (gdb) print * (int *) &main
  Warning: cast converts pointer from code space to data space.
  Perhaps you should use (@code int *) instead.
  $2 = 42
  (gdb)

If the user spells out the space, GDB could keep its mouth shut:

  (gdb) print * (@data int *) &main
  $3 = 42
  (gdb)

> ``Note below'':
> 
> 
> The basic framework attached the segment information to the pointee 
> rather than pointer.  Was this an arbitrary decision or based on some 
> theoretical framework.

I think the following rule is worth preserving:

  - If an expression E has some type T, then &E has type T *.

This is a fundamental operation, and choosing the wrong behavior here
will inevitably cause troubles elsewhere, too.

Suppose you attach the qualifier to the pointer, and not the pointee.
That is, `@code' may only be applied to pointer types, and it means
that the pointer points to something in code space.

    Now suppose that `q' is an int living in code space.  Since
    qualifiers apply to pointers only, q's type must be simply `int'.
    You'd like `&q' to have the type `int * @code', but the `&' rule
    above requires q's type must be simply `int'.  So you have to
    break the `&' rule, or get stupid behavior.

    Also, there isn't any nice, compact way to describe what q is.
    The best you can say is, "q is an int in code space," as I did
    above.

Suppose, on the other hand, that you attach a space qualifier to an
object, indicating that it lives in that space.  That is, `@code' may
be applied to any type, and it means the object itself lives in code
space.

    Suppose again that `q' is an int living in code space.  Since
    qualifiers apply to objects, q's type must be `@code int'.  As
    above, you'd like `&q' to have type `@code int *'.  (This is the
    same type as above --- pointer to int in code space --- just
    written according to the new syntax) And this is in fact the type
    the `&' rule requires.  All is well.

    Also, there is a nice way to describe q.  You can simply say, "q
    is a @code int", or "@code int q".

So the latter is what Michael proposed.

> Since the pointee gets the attribute it is possible to construct things 
> like:
> 
> 	(@code struct { @data int i; @io unsigned char *@data c; } *)
> 
> was this the intent?  (I suspect it was: having a @data -> @io space 
> pointer sitting in code memory, while sick, is still plausable).

You can't have a struct living in code space with a member in data
space; a struct's members live in the same space as the struct itself.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>  - If an expression E has some type T, then &E has type T *.

To be pedantic:

	An expression E has some type T, then &E has type T *@data.

It is defining a pointer from data space to either code or data space.

> This is a fundamental operation, and choosing the wrong behavior here
> will inevitably cause troubles elsewhere, too.
> 
> Suppose you attach the qualifier to the pointer, and not the pointee.
> That is, `@code' may only be applied to pointer types, and it means
> that the pointer points to something in code space.

Sorry, you've lost me.  What is being discussed is the cast operator and 
its semantics. A cast takes a type and expression parameter and returns 
an expression.

To the best of my knowledge, ISO C says nothing about cast operations 
that convert between code and data pointers.  What we do have is a 
certain level of accepted behavour.  For instance on a unified byte 
addressable address space architecture things like:

	sizeof(void*) == sizeof((*)())
	((*)()) (void*) foo == ((*)()) foo

However, on a harvard address space architecture we have none of that.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> >  - If an expression E has some type T, then &E has type T *.
> 
> To be pedantic:
> 
> 	An expression E has some type T, then &E has type T *@data.
> 
> It is defining a pointer from data space to either code or data
> space.

If something isn't an lvalue, the space qualifier is meaningless.

> > This is a fundamental operation, and choosing the wrong behavior here
> > will inevitably cause troubles elsewhere, too.
> > 
> > Suppose you attach the qualifier to the pointer, and not the pointee.
> > That is, `@code' may only be applied to pointer types, and it means
> > that the pointer points to something in code space.
> 
> Sorry, you've lost me.  What is being discussed is the cast operator and 
> its semantics. A cast takes a type and expression parameter and returns 
> an expression.

That was meant to answer the following question you asked:

> The basic framework attached the segment information to the pointee 
> rather than pointer.  Was this an arbitrary decision or based on some 
> theoretical framework.



> To the best of my knowledge, ISO C says nothing about cast operations 
> that convert between code and data pointers.  What we do have is a 
> certain level of accepted behavour.  For instance on a unified byte 
> addressable address space architecture things like:
> 
> 	sizeof(void*) == sizeof((*)())
> 	((*)()) (void*) foo == ((*)()) foo
> 
> However, on a harvard address space architecture we have none of that.

Right.  We don't.  What's your point?

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>> To the best of my knowledge, ISO C says nothing about cast operations 
>> that convert between code and data pointers.  What we do have is a 
>> certain level of accepted behavour.  For instance on a unified byte 
>> addressable address space architecture things like:
>> 
>> sizeof(void*) == sizeof((*)())
>> ((*)()) (void*) foo == ((*)()) foo
>> 
>> However, on a harvard address space architecture we have none of that.
> 
> 
> Right.  We don't.  What's your point?

Compilers, such as GCC implement:

	int *i = &func;

based on the assumption that sizeof(i) == sizeof(&func) - that is the 
operation is a simple copy.

I think it is reasonable to expect that one day there will be targets 
that have sizeof(i) < sizeof(&func) (or vice versa) which would then 
make the above totally meaningless - the value would be truncated during 
the transfer.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>> Since the pointee gets the attribute it is possible to construct things 
>> like:
>> 
>> (@code struct { @data int i; @io unsigned char *@data c; } *)
>> 
>> was this the intent?  (I suspect it was: having a @data -> @io space 
>> pointer sitting in code memory, while sick, is still plausable).
> 
> 
> You can't have a struct living in code space with a member in data
> space; a struct's members live in the same space as the struct itself.


The syntax change will allow it even though it is probably meaningless 
(Mind you, i've this fuzzy memory of a language (ada?, VAX pascal?) 
allowing you to specify sparse structures.)

With regard to a @data->@io pointer.  That is probably wrong.  Pointers, 
which are typically implemented as address registers (not to be confused 
with GDB's core addr), have a fixed size for a given address space.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> With regard to a @data->@io pointer.  That is probably wrong.  Pointers, 
> which are typically implemented as address registers (not to be confused 
> with GDB's core addr), have a fixed size for a given address space.

Not sure what you mean here.  A value of type `@io foo *' is perfectly
meaningful.  Its size depends on characteristics of the I/O space.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> With regard to a @data->@io pointer.  That is probably wrong.  Pointers, 
>> which are typically implemented as address registers (not to be confused 
>> with GDB's core addr), have a fixed size for a given address space.
> 
> 
> Not sure what you mean here.  A value of type `@io foo *' is perfectly
> meaningful.  Its size depends on characteristics of the I/O space.

What about ``@io int *@code''?  The pointer's size is independant (well 
at least for the moment) of the source address space.  Hence the 
attribute attached to the pointer (instead of pointee) adds nothing.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > Andrew Cagney <ac131313@cygnus.com> writes:
> > 
> >> With regard to a @data->@io pointer.  That is probably wrong.  Pointers, 
> >> which are typically implemented as address registers (not to be confused 
> >> with GDB's core addr), have a fixed size for a given address space.
> > 
> > 
> > Not sure what you mean here.  A value of type `@io foo *' is perfectly
> > meaningful.  Its size depends on characteristics of the I/O space.
> 
> What about ``@io int *@code''?  The pointer's size is independant (well 
> at least for the moment) of the source address space.  Hence the 
> attribute attached to the pointer (instead of pointee) adds nothing.

The declaration

        @io int * @code x;

would declare a variable x in code space that points to an int in io
space.  Of course, GDB doesn't do declarations.

For casts, sure; the latter qualifier in `(@io int * @code) 0x10' is
meaningless.  Address space qualifiers are meaningless applied to
rvalues, as are `const' and `volatile'.  In `(int * const) x', the
`const' is meaningless, too, because the result of a cast expression
isn't an lvalue.

What's your point?

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:
> 
>> > Andrew Cagney <ac131313@cygnus.com> writes:
>> > 
> 
>> >> With regard to a @data->@io pointer.  That is probably wrong.  Pointers, 
>> >> which are typically implemented as address registers (not to be confused 
>> >> with GDB's core addr), have a fixed size for a given address space.
> 
>> > 
>> > 
>> > Not sure what you mean here.  A value of type `@io foo *' is perfectly
>> > meaningful.  Its size depends on characteristics of the I/O space.
> 
>> 
>> What about ``@io int *@code''?  The pointer's size is independant (well 
>> at least for the moment) of the source address space.  Hence the 
>> attribute attached to the pointer (instead of pointee) adds nothing.
> 
> 
> The declaration
> 
>         @io int * @code x;
> 
> would declare a variable x in code space that points to an int in io
> space.  Of course, GDB doesn't do declarations.
> 
> For casts, sure; the latter qualifier in `(@io int * @code) 0x10' is
> meaningless.  Address space qualifiers are meaningless applied to
> rvalues, as are `const' and `volatile'.  In `(int * const) x', the
> `const' is meaningless, too, because the result of a cast expression
> isn't an lvalue.

Yes, I just said that.

> What's your point?

``With regard to a @data->@io pointer.  That [my comment] is probably 
wrong'' vis:

 > having a @data -> @io space pointer sitting in code memory, while 
sick, is still plausable.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

I got curious and worked through this:

> I think the following rule is worth preserving:
> 
>   - If an expression E has some type T, then &E has type T *.
> 
> This is a fundamental operation, and choosing the wrong behavior here
> will inevitably cause troubles elsewhere, too.
> 
> Suppose you attach the qualifier to the pointer, and not the pointee.
> That is, `@code' may only be applied to pointer types, and it means
> that the pointer points to something in code space.
> 
>     Now suppose that `q' is an int living in code space.  Since
>     qualifiers apply to pointers only, q's type must be simply `int'.
>     You'd like `&q' to have the type `int * @code', but the `&' rule
>     above requires q's type must be simply `int'.  So you have to
>     break the `&' rule, or get stupid behavior.
> 
>     Also, there isn't any nice, compact way to describe what q is.
>     The best you can say is, "q is an int in code space," as I did
>     above.
> 
> Suppose, on the other hand, that you attach a space qualifier to an
> object, indicating that it lives in that space.  That is, `@code' may
> be applied to any type, and it means the object itself lives in code
> space.
> 
>     Suppose again that `q' is an int living in code space.  Since
>     qualifiers apply to objects, q's type must be `@code int'.  As
>     above, you'd like `&q' to have type `@code int *'.  (This is the
>     same type as above --- pointer to int in code space --- just
>     written according to the new syntax) And this is in fact the type
>     the `&' rule requires.  All is well.
> 
>     Also, there is a nice way to describe q.  You can simply say, "q
>     is a @code int", or "@code int q".
> 
> So the latter is what Michael proposed.

I think that there are several things kicking around here.


The syntax:

The @<region> attribute being attached to the pointee rather than 
pointer.  As you note, a syntax which attached the attribute to the 
pointer would lead to unnatural behavour in the C language.


The representation within GDB.

GDB's ``struct type'' needs to be  modified so that it includes the 
space that a pointer is designating.  Michael added it to the pointee so 
that it matched the syntax.  As a consequence, both the syntax and the 
modified type system allow the representation of meaningless types such 
as ``@code struct { @data int i; }''.

I suspect that ``struct type'' could be modified so that the address 
space attribute is stored with the pointer rather than pointee. 
However, I take it from Michael and your comments that this would lead 
to a cumbersom implementation - there is no longer a simple 1:1 mapping 
between the syntax and GDB's internal data structures.


Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> >> (gdb) print/x *(int*)foo
> >> 0xdeadbeef
> >
> >
> > An (int *) is by default a data pointer.
> > A function pointer is by default a code pointer.
> 
> As far as I know, the C language says nothing about the above (assuming
> foo is a function). 

Of course.  I was describing GDB's current behavior.

> It is an implementation defined pointer cast open
> to any interpretation.  All it defines are ``pointer from data to data
> space'' and ``pointer from data to code space''.  It doesn't even define
> foo+4, where foo is a function.
> 
> Any way, lets break down the proposal.
> 
> --
> 
> Firstly it is adding a mechanism that will allow GDB to represent
> pointers to / from / within any address space.

Well, technically, it is extending a mechanism that GDB already uses.
The current mechanism is that expressions that point to a data-like type
(scalar, struct, array-of-data-like type etc.) point to data space, and
expressions that point to functions point to code space.  My proposal
is giving the user the ability to override this default behavior.



> We absolutly need this.  And such a change can probably be dropped right
> in. However check note below.
> 
> --
> 
> Next we've got the syntax change - an attribute extension.  While querky
>   it doesn't worry me - if I'm understanding it correctly, it is
> possible to add syntatic sugar for common operations (such as references
> to code space) [see other e-mail]. (However do check note below :-)
> 
> --
>
> Finally, there are the semantics of the operations.  Here I think we're
> clearly disagreeing.  I'm arguing that an address is an address is an
> address - it always designates the one location - unless explicitly
> converted.  In the proposal it silently moves depending on what was
> done.  The  pointer cast operator is being given certain semantics - I
> think those semantics are not what the user expects.

We should discuss in detail what the semantics currently are, 
vs. what the proposal would change them to.  I'm not sure we are
on the same page about either of those.

For instance, it's not true that currently "an address is an address".
Without my change, it is already possible to cast a function (code) address
into a data address.  An example that you gave earlier already does this:

	print *(int *) main

will give the value of the int residing in the data-space address
corresponding to the code-space address of main.  Currently it is 
not possible to type an expression that refers to the int residing
in the CODE-SPACE address of main.  My extension gives that ability.


> Per my previous comment, given a function foo.  I'd contend that the
> user is going to expect the expression:
> 
>         *(int*)foo
> 
> to print an integer at address foo and not at some other data address.

Perhaps -- but that's not what currently would happen.
We can probably have a long debate about what a user would expect.
But I point out that without my change, the user has no way to do
what you suggest, whereas with my change he does.


> BTW, regarding ``(int *)'' is always ``(@data int *@data)'' that is
> true.  Rember though that the above is really:
> 
>         cast ((int*), (@code *@data))
> 
> and as far as I know, this operation isn't defined by C? 

I'm sure that's true.

> It is free to
> apply arbitrary transformations that might include:
> 
>         (@data int *@data)
> or
> (@code int *@data)
> 
> Any way, if GDB is going to have an address changes model (I consider
> this user broken) then, at a minimum, it should warn the user that an
> address space change has been applied to their apparently simple address
> expression.

Perhaps.

> 
> --
> 
> ``Note below'':
> 
> The basic framework attached the segment information to the pointee
> rather than pointer.  Was this an arbitrary decision or based on some
> theoretical framework.

It seems to me to make the most sense (and Jim Blandy seems to agree).
It gives you the ability to construct arbitrary combinations, such as
a data-space pointer to a data-space pointer to a code-space int.


> Since the pointee gets the attribute it is possible to construct things
> like:
> 
>         (@code struct { @data int i; @io unsigned char *@data c; } *)
>
> was this the intent? 

Not explicitly, no -- but along with the power to construct arbitrary
expressions comes the ability to construct expressions that don't make
much sense.  Debuggers sometimes have more power than you would have
in the native language (for instance, you can modify the private data
of a C++ class).  With this power comes the ability to shoot yourself
in the foot -- users have to know this.  The debugger doesn't warn you
when you modify the private data of a base class.

To show a simple example, the parser that I've submitted will accept
the expression "(@code @code int)".  That doesn't make terribly much
sense, but it's harmless.  It will also probably accept the expression
"(@code @data int)".  That's more serious, and should probably be an error.

> (I suspect it was: having a @data -> @io space
> pointer sitting in code memory, while sick, is still plausable).
> 
> Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:

> ``Note below'':
> 
> The basic framework attached the segment information to the pointee
> rather than pointer.  Was this an arbitrary decision or based on some
> theoretical framework.

Can't tell if I've adequately answered this.  The design decision
was: make the address-modifier behave syntactically like the
const-modifier and volatile-modifier.  I figured that was easiest
to implement (already had an example), easiest to explain
("it's just like const"), and already known to be powerful
enough to modify any data type.  Since the address modifier
can be used in a context similar to the const and volatile
modifiers, I would have needed a pretty good reason to make
it syntactically different from them.  I couldn't think of one.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Andrew Cagney wrote:
> 
> 
>> ``Note below'':
>> 
>> The basic framework attached the segment information to the pointee
>> rather than pointer.  Was this an arbitrary decision or based on some
>> theoretical framework.
> 
> 
> Can't tell if I've adequately answered this.  The design decision
> was: make the address-modifier behave syntactically like the
> const-modifier and volatile-modifier.  I figured that was easiest
> to implement (already had an example), easiest to explain
> ("it's just like const"), and already known to be powerful
> enough to modify any data type.  Since the address modifier
> can be used in a context similar to the const and volatile
> modifiers, I would have needed a pretty good reason to make
> it syntactically different from them.  I couldn't think of one.

Thanks!

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Andrew Cagney wrote:
> >
> >
> >> ``Note below'':
> >>
> >> The basic framework attached the segment information to the pointee
> >> rather than pointer.  Was this an arbitrary decision or based on some
> >> theoretical framework.
> >
> >
> > Can't tell if I've adequately answered this.  The design decision
> > was: make the address-modifier behave syntactically like the
> > const-modifier and volatile-modifier.  I figured that was easiest
> > to implement (already had an example), easiest to explain
> > ("it's just like const"), and already known to be powerful
> > enough to modify any data type.  Since the address modifier
> > can be used in a context similar to the const and volatile
> > modifiers, I would have needed a pretty good reason to make
> > it syntactically different from them.  I couldn't think of one.
> 
> Thanks!

OK -- so where do we stand?  Are you OK with this patch going in?
To be refined later as necessary?

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Thanks!
> 
> 
> OK -- so where do we stand?  Are you OK with this patch going in?
> To be refined later as necessary?

I'm ok with the current set of changes (need to contact David Taylor 
though).  The debate is about the semantics of a type cast and that 
depends on this change being present.

While this is happening, can I suggest cleaning things up a little - 
stray +/- blank lines, coding standard and some missing ChangeLog 
entries (TYPE_AS_TYPE?).

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Thanks!
> >
> >
> > OK -- so where do we stand?  Are you OK with this patch going in?
> > To be refined later as necessary?
> 
> I'm ok with the current set of changes (need to contact David Taylor
> though).  The debate is about the semantics of a type cast and that
> depends on this change being present.
> 
> While this is happening, can I suggest cleaning things up a little -
> stray +/- blank lines, coding standard and some missing ChangeLog
> entries (TYPE_AS_TYPE?).

After some delay, I'm ready to resubmit this, with clean-ups.
Since it's been so long (and this thread is so long too), I'll
start a new thread.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Any way, consider the intent of someone entering a sequence like:
> 
> 	(gdb) x/w foo
> 	0x0
> 	(gdb) x/i foo
> 	nop
> 	(gdb) print/x *(int*)foo
> 	0xdeadbeef
> 
> vs 
> (gdb) print/x *(int*)foo
> 	0x0
> 
> and where should this go:
> 
> 	(gdb) set *(int*)foo = 0xdeadbeef
> 
> This mysterious address switching strikes me as wierd.

It *is* weird, but I think it's an intrinsic weirdness of Harvard
architectures that it would be a disservice to conceal.

Seriously, you can't protect the user from the oddities of the chip
they're working on.  And I think we shouldn't: GDB's job is to help
people observe the behavior of the program, and tools for observation
must be careful not to edit reality too much.  It's perfectly okay to
tell someone, "You don't understand your architecture; do it this
way."  (Rather, the manual should say this, and we should point them
at it.)

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>> Any way, consider the intent of someone entering a sequence like:
>> 
>> (gdb) x/w foo
>> 0x0
>> (gdb) x/i foo
>> nop
>> (gdb) print/x *(int*)foo
>> 0xdeadbeef
>> 
>> vs 
>> (gdb) print/x *(int*)foo
>> 0x0
>> 
>> and where should this go:
>> 
>> (gdb) set *(int*)foo = 0xdeadbeef
>> 
>> This mysterious address switching strikes me as wierd.
> 
> 
> It *is* weird, but I think it's an intrinsic weirdness of Harvard
> architectures that it would be a disservice to conceal.
> 
> Seriously, you can't protect the user from the oddities of the chip
> they're working on.  And I think we shouldn't: GDB's job is to help
> people observe the behavior of the program, and tools for observation
> must be careful not to edit reality too much.  It's perfectly okay to
> tell someone, "You don't understand your architecture; do it this
> way."  (Rather, the manual should say this, and we should point them
> at it.)

We're also expected to make GDB user friendly.

In the above, if the user wanted to convert the function pointer into a 
data pointer then they would enter:

	(@data int *)foo

and who knows what the result would be.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> >> Any way, consider the intent of someone entering a sequence like:
> >>
> >> (gdb) x/w foo
> >> 0x0
> >> (gdb) x/i foo
> >> nop
> >> (gdb) print/x *(int*)foo
> >> 0xdeadbeef
> >>
> >> vs
> >> (gdb) print/x *(int*)foo
> >> 0x0
> >>
> >> and where should this go:
> >>
> >> (gdb) set *(int*)foo = 0xdeadbeef
> >>
> >> This mysterious address switching strikes me as wierd.
> >
> >
> > It *is* weird, but I think it's an intrinsic weirdness of Harvard
> > architectures that it would be a disservice to conceal.
> >
> > Seriously, you can't protect the user from the oddities of the chip
> > they're working on.  And I think we shouldn't: GDB's job is to help
> > people observe the behavior of the program, and tools for observation
> > must be careful not to edit reality too much.  It's perfectly okay to
> > tell someone, "You don't understand your architecture; do it this
> > way."  (Rather, the manual should say this, and we should point them
> > at it.)
> 
> We're also expected to make GDB user friendly.
> 
> In the above, if the user wanted to convert the function pointer into a
> data pointer then they would enter:
> 
>         (@data int *)foo
> 
> and who knows what the result would be.

The result would be a data address corresponding to the 
code address 'foo'.  For example, if code addresses have their
32nd bit set and data addresses do not, then the address of foo
might be 0x80001234, and (@data int *) foo would be 0x1234.
BTW, (int *) foo would also be 0x1234, because an int pointer
is by default located in data space.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> We're also expected to make GDB user friendly.
>> 
>> In the above, if the user wanted to convert the function pointer into a
>> data pointer then they would enter:
>> 
>> (@data int *)foo
>> 
>> and who knows what the result would be.

Mild sarcasm :-)

> The result would be a data address corresponding to the 
> code address 'foo'.  For example, if code addresses have their
> 32nd bit set and data addresses do not, then the address of foo
> might be 0x80001234, and (@data int *) foo would be 0x1234.
> BTW, (int *) foo would also be 0x1234, because an int pointer
> is by default located in data space.

A specific combination of ISA and C language implementation will always 
give the above meaning.  However, each such combination will result in a 
different behavour.  On the d10v it is:

(*foo)() = 0x1234; // 0x010048d0
char *c = foo; // 0x2001234
The C language spec has nothing to say about how this should be 
interpreted.  As they say, ``we're making this up as we go along'' :-)

Going back to my point ``user friendly''.  When, if ever, would a user 
want to evaluate the expression:

	(@data int *@data) func

(aka ``(int*)func'') compared to a desire to evaluate the expression:

	(@code int *@data) func

(aka ``(@code int *) func'').

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

[Sorry, replying to several messages and repeating myself a bit.]

Andrew Cagney <ac131313@cygnus.com> writes:
> Any way, consider the intent of someone entering a sequence like:
> 
> 	(gdb) x/w foo
> 	0x0
> 	(gdb) x/i foo
> 	nop
> 	(gdb) print/x *(int*)foo
> 	0xdeadbeef
> 
> vs 
> (gdb) print/x *(int*)foo
> 	0x0
> 
> and where should this go:
> 
> 	(gdb) set *(int*)foo = 0xdeadbeef
> 
> This mysterious address switching strikes me as wierd.

This is an existing problem.  Any C compiler for a machine with distinct
code and data address spaces will do the same thing.

The value of the proposal Michael and I have put together is not that
it solves all possible problems, or that it makes counterintuitive
architectures somehow behave like more familiar architectures.  The
value is that it allows a user to accomplish what they want at all.

I think our proposal:
- adapts to other sorts of spaces well,
- has a consistent type story, and 
- doesn't change the meaning of any valid C expressions.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

Jim,

> - doesn't change the meaning of any valid C expressions

Is this a valid C expression?

	int foo();
	char *c = foo;

I.e. does ISO C define its semantics?

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > - doesn't change the meaning of any valid C expressions
> 
> Is this a valid C expression?
> 
> 	int foo();
> 	char *c = foo;
> 
> I.e. does ISO C define its semantics?

No, it's not a valid C expression.  It's a declaration, followed by a
definition with an initializer.  :)

The expression:

        (int *) &func

is a valid C expression.  Its meaning is unspecified by ISO C, but
every compiler does assign some meaning to it.  The same applies to
your example.

If I understand you correctly, you would like GDB to evaluate that
expression in a way which yields a pointer to an int in code space.
You argue that, since this expression's meaning is not fixed by the
standard, GDB is free to interpret it in whatever way is most helpful
to the user.  Is that correct?

While the expression's meaning is not fixed by the standard, the
compiler does assign some meaning to it.  I feel it is important that
GDB should produce the same value for an expression that the compiler
would.  So I feel that GDB is not, in fact, free to make the
interpretation you suggest.

You've said that the compiler's interpretation is useless.  Probably
so.  But what if the user's bug is that they have cast a function
pointer to a data pointer, and tried to use it to fetch the
instructions?  If they try their expression in GDB, they should get
the same (unexpected!) answer that GCC gives them.  This consistency
is, in fact, critical to them finding their bug!

So, what I meant by the assertion quoted by you at the top of this
message is: our proposal does not require GDB to evaluate any
expressions differently than the compiler would.  It is strictly an
extension of the language accepted by the compiler.  Your suggested
change would assign expressions like `(int *) &func' a meaning
different from the one the compiler would.  This is, to my mind, a
serious point against it.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Frank Ch. Eigler]

cagney wrote:

: > - doesn't change the meaning of any valid C expressions
: 
: Is this a valid C expression?
: 
: 	int foo();
: 	char *c = foo;
: 
: I.e. does ISO C define its semantics?

A mere pointer assignment?  There is not much possible semantics there
to worry about.  Yes, it'd be illegal to dereference the char* pointer.
It may be legal to cast it back to "int (*) ()" and call through that,
if "char*" is as big as "int (*) ()".

Some of this discussion seems to me to focus too much on how
fundamentally nonsensical operations may be expressed in nonsensical
gdb expression syntax.

- FChE

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > What about expressions.
> >
> > Consider
> >     (gdb) print (char *) function
> >
> > should that return:
> >
> >     (@data char *) ...
> > or (@code char *) ...
> 
> Oops, pressed the wrong button ...
> 
> My question here is, should the address space be propogated through a
> type conversion (when it isn't explicitly specified)?
> 
> The user might have the expression:
> 
>         x/i function
> 
> and then enter
> 
>         x/w function
> 
> Both will examine the same memory location. 

Correct.  The code-space memory location.

> The user could then try to
> manipulate that data with:
> 
>         print *(int*)function
> 
> however, depending on the interpretation of the expression (I don't
> believe ISO C defines the semantics of this)

Correct (AFAIK).

> you could end up printing a
> value from a completly different address space.

The above operation works even without my change.  Since (int*) 
is interpreted as a naturally "data-like" expression, the above
will give you the int that lives in the data-space address corresponding
to the code-space address of "function".

What my change _adds_ to this picture is the ability to say

	print *(@code int *) function

which will print the int that resides in the CODE-SPACE address
corresponding to the address of "function".  This is something
that you cannot do without my change.

> Would it be better if the cast operator, by default, preserved the
> address space of the pointer being cast?

That would be _more_ of a change than my proposed change.
As such, I think that that change can be discussed independently
of my proposed change.  The current behavior of GDB (without my
change) is that a cast to a data-like type always refers to 
data space, and a cast to a function-like type always refers
to code space.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> 
> Correct (AFAIK).
> 
> 
>> you could end up printing a
>> value from a completly different address space.
> 
> 
> The above operation works even without my change.  Since (int*) 
> is interpreted as a naturally "data-like" expression, the above
> will give you the int that lives in the data-space address corresponding
> to the code-space address of "function".
> 
> What my change _adds_ to this picture is the ability to say
> 
> 	print *(@code int *) function
> 
> which will print the int that resides in the CODE-SPACE address
> corresponding to the address of "function".  This is something
> that you cannot do without my change.

Without change.  My contention is that the user is almost never going to 
want to do what you just described.  Why make what the user is going to 
want to do hard?

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> >
> > Correct (AFAIK).
> >
> >
> >> you could end up printing a
> >> value from a completly different address space.
> >
> >
> > The above operation works even without my change.  Since (int*)
> > is interpreted as a naturally "data-like" expression, the above
> > will give you the int that lives in the data-space address corresponding
> > to the code-space address of "function".
> >
> > What my change _adds_ to this picture is the ability to say
> >
> >       print *(@code int *) function
> >
> > which will print the int that resides in the CODE-SPACE address
> > corresponding to the address of "function".  This is something
> > that you cannot do without my change.
> 
> Without change.  My contention is that the user is almost never going to
> want to do what you just described.  Why make what the user is going to
> want to do hard?

This whole change was prompted by a user's request to be able
to do just that.  Well, actually, he wanted to be able to do

        set *(@code short *) myfunction = 0xabcd

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Without change.  My contention is that the user is almost never going to
>> want to do what you just described.  Why make what the user is going to
>> want to do hard?
> 
> 
> This whole change was prompted by a user's request to be able
> to do just that.  Well, actually, he wanted to be able to do
> 
>         set *(@code short *) myfunction = 0xabcd


I think everyone is in agreement that not being able to frob an 
instruction location is a ``breakage''.  Can I guess they entered:

	set *(short *) myfunc = 0xabcd

I would.  And as I'm doing now, I would also be asking why I have to 
explicitly specify @code, when the cast operator already knows that my 
pointer is designating code space.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > Without change.  My contention is that the user is almost never going to
> >> want to do what you just described.  Why make what the user is going to
> >> want to do hard?
> >
> >
> > This whole change was prompted by a user's request to be able
> > to do just that.  Well, actually, he wanted to be able to do
> >
> >         set *(@code short *) myfunction = 0xabcd
> 
> I think everyone is in agreement that not being able to frob an
> instruction location is a ``breakage''.  Can I guess they entered:
> 
>         set *(short *) myfunc = 0xabcd
> 
> I would.  And as I'm doing now, I would also be asking why I have to
> explicitly specify @code, when the cast operator already knows that my
> pointer is designating code space.

Your intuition is counter to what GCC actually implements.
Your hypothetical user might have the same intuition as you, 
but if he's using GCC, then his intuition may actually be
the source of the bug he's trying to debug.  GCC evaluates
the expression:

	x = *(int *) &main;

by taking a value from data space.  I think GDB should be 
able to cut and paste the expression from the source code
and give the same result that the compiler gives.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Without change.  My contention is that the user is almost never going to 
> want to do what you just described.  Why make what the user is going to 
> want to do hard?

Michael's change makes what the user wants possible at all, which is
an improvement over the current situation.  You are asking for an
additional improvement, which can be discussed separately from
Michael's change.

But to answer the question anyway:

Sometimes it is better to leave what the user usually wants to do
somewhat hard, because making that specific case easy makes a lot of
other stuff even weirder.

You're essentially proposing:
- that a cast expression like (T) EXPR would not result in a value of
  type T, but some other type chosen to save the user's keystrokes, and
- that we make GDB evaluate expressions like `(int *) &main' differently
  from the way the compiler does.

Those set off warning bells, for me.  You can special-case this stuff
to make the naive user's behavior do the right thing want all you
want.  If you've ever had Microsoft Word correct your capitalization
or automatically munge your paragraph formatting, you know what the
resulting systems feel like to use.

In contrast, once you do explain to someone how to do what they want
under Michael's and my proposal, it makes sense, given the
architecture.  You can then correctly predict how a half-dozen other
weird things would be done.  All the rules you already know about
types apply naturally to the extension.

As I see it, these architectures have a discontinuity that we're
simply not accustomed to, though people in older times wouldn't have
been so surprised.  And we've provided a way to accurately describe
that sort of discontinuity; using our system, things "just work" that
can't be made to work without our system.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

> Andrew Cagney <ac131313@cygnus.com> writes:

> Michael's change makes what the user wants possible at all, which is
> an improvement over the current situation.  You are asking for an
> additional improvement, which can be discussed separately from
> Michael's change.

Ah! Thankyou!

> You're essentially proposing:
> - that a cast expression like (T) EXPR would not result in a value of
>   type T, but some other type chosen to save the user's keystrokes, and

Yes.

> - that we make GDB evaluate expressions like `(int *) &main' differently
>   from the way the compiler does.

and that this isn't defined at all.  It does have a loose definition on 
unified address space architectures.

> Those set off warning bells, for me.  You can special-case this stuff
> to make the naive user's behavior do the right thing want all you
> want.  If you've ever had Microsoft Word correct your capitalization
> or automatically munge your paragraph formatting, you know what the
> resulting systems feel like to use.

Have a look at the way GDB vs GCC implements ``func + 4'' for AIX.  We 
do this now.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> > - that we make GDB evaluate expressions like `(int *) &main' differently
> >   from the way the compiler does.
> 
> and that this isn't defined at all.  It does have a loose definition on 
> unified address space architectures.

Is is defined --- not by the standard, but by GCC.  It is very
important that GDB's expression evaluation match GCC's.

> > Those set off warning bells, for me.  You can special-case this stuff
> > to make the naive user's behavior do the right thing want all you
> > want.  If you've ever had Microsoft Word correct your capitalization
> > or automatically munge your paragraph formatting, you know what the
> > resulting systems feel like to use.
> 
> Have a look at the way GDB vs GCC implements ``func + 4'' for AIX.  We 
> do this now.

And indeed, that discrepancy is undesirable, right?  We should not
introduce more.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>  Have a look at the way GDB vs GCC implements ``func + 4'' for AIX.  We 
>> do this now.
> 
> 
> And indeed, that discrepancy is undesirable, right?  We should not
> introduce more.

The above discrepency is very desireable, the last thing we want to do 
is fix GDB making it behave like GCC.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

>> > Those set off warning bells, for me.  You can special-case this stuff
>> > to make the naive user's behavior do the right thing want all you
>> > want.  If you've ever had Microsoft Word correct your capitalization
>> > or automatically munge your paragraph formatting, you know what the
>> > resulting systems feel like to use.
> 
>> 
>> Have a look at the way GDB vs GCC implements ``func + 4'' for AIX.  We 
>> do this now.
> 
> 
> And indeed, that discrepancy is undesirable, right?  We should not
> introduce more.

To be honest, I think GCC has a bug.  In the case of AIX it is 
implementing meaningless behavour by accident.  I think GCC, if nothing 
else, should issue a warning.

To expand on the problem, (kevin correctly me if I'm wrong).  AIX has 
function descriptors and a C function pointer designates a descriptor 
(in data space) and not the code of the function.  Thus, what to the C 
programmer looks like (to use pseudo pascal syntax):

	pointer to function

is implemented as:

	pointer to record
	  pointer to function;
	  pointer to table_of_contents;
	  pointer to something else;
	end

When GCC encounters:

	function + 1

it implements

	&function + 1

Remembering that a function pointer points to a record/struct in data 
space (and not the actual function) the above ends up pointing to what 
ever lies beyond the function descriptor in data memory.

GDB on the other hand implements the above as

	function+1

(i.e. the second byte (should it be word?) of function's code).

Anyway, my point here is that I don't think GCC should be held up as the 
reference implementation.  Just like in GDB, I suspect GCC has edge 
cases that no one has thought through.

enjoy,
Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Anyway, my point here is that I don't think GCC should be held up as the 
> reference implementation.  Just like in GDB, I suspect GCC has edge 
> cases that no one has thought through.

I completely agree that GDB's behavior is more useful than GCC's.
Having GCC generate a warning message for such expressions, or
(golly!) disable the extension to standard C that allows arithmetic on
function pointers for that ABI, sound much better to me.

The reason I hold up GCC as the reference implementation has nothing
to do with admiration of GCC.  It is because the program the user is
trying to understand was compiled with GCC.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

Jim,

Something to keep in mind here.  Two things are being created.  A 
framework and a user interface.

The framework is easy to change if it turns out to have problems.  The 
user interface isn't.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> Jim,
> 
> Something to keep in mind here.  Two things are being created.  A
> framework and a user interface.
> 
> The framework is easy to change if it turns out to have problems.  The
> user interface isn't.
> 
> Andrew

Would you mind summarizing exactly which parts of the user 
interface you would like to discuss changing?  I appologize --
it's just that this thread has exceeded 40 messages and I'm
not sure anymore exactly what's on the table.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Michael Snyder]

Andrew Cagney wrote:
> 
> > This is an extension to help with debugging on Harvard architectures
> > (machines with two or more address spaces, typically one for
> > instructions and one for data).  The idea here is to provide the user
> > with a mechanism for specifying the address space of a pointer or
> > a raw address (eg. to display the contents of code memory as opposed
> > to data memory, when the address alone is not enough to differentiate).
> >
> > Rather than provide extensions for specific commands such as print
> > and examine, it seemed more useful and general to provide an
> > extension to the syntax for type expressions.  Thus we can identify
> > a pointer to (say) code address space by using a pointer cast, and
> > that expression can be used in any command that accepts an expression.
> >
> >       (gdb) x /xb (@code short *) foo
> >       (gdb) print *(@data char *) 0x1000
> >       (gdb) set *(@code long long *) 0x1000 = 0
> >
> > The idea is that the modifiers "@code" and "@data" can be used
> > anywhere where it would be legal to use "const" or "volatile".
> > I've used the "@" character to remove the new keywords from the
> > user name space, but I'm open to discussion on that choice
> > ("$" might be another possibility).
> >
> > So, for instance, a (@code int *) would be a pointer to an int in
> > code space, while a (int * @code) would be a pointer in code space
> > to an int (presumably in data space).
> 
> The syntax feels long winded - which probably isn't unexpected.  It is
> playing around with a type system.  Shortened / abreviated forms are
> going to be useful.
> 
> I know Fche once suggested:
> 
>         x/i $code + 100
> 
> where $code designates a code base address.  I guess, using the above,
> $code would be syntatic sugar for ``(@code char *) 0'' giving ``(@code
> char *)0 + 100'' for the above.

That can be done as a future extension.  It's not precluded by this change, 
and in fact this change will facilitate that one ("$code" can be declared
as an array of (@code int)).

> --
> 
> Looking at the output and how it interacts.  I'll give several examples
> and possible outputs:
> 
>         (gdb) print (@data char *) 0x1000
> 
>         (@data char *) 0x1000
> or
> (char *) 0x1000
> 
>         (gdb) print ((@code *)()) 0x1000
> (I think)
> 
>         ((@code *)()) 0x1000
> or
> ((*)()) 0x1000
> 
> I think in each case it should display the latter - the ``@code''
> attribute is redundant information.  Only when the space conflicts with
> the values type should it be displayed.

My current patch includes only minimal changes to gdb's output.
Others can be added if the need is identified.

> 
> --
> 
> What about expressions.
> 
> Consider
>         (gdb) print (char *) function
> 
> should that return:
> 
>         (@data char *) ...
> or
> (@code char *) ...

What it actually returns is something like:

$1 = 0x1272 ""
Where 0x1272 is the data space form of the address of function, and
"" is the string that resides at that address (in data space).  
This is logical, because (char *) is a data-like type.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Eli Zaretskii]

> Date: Fri, 28 Sep 2001 13:06:27 -0700
> From: Michael Snyder <msnyder@cygnus.com>
> 
> This is an extension to help with debugging on Harvard architectures
> (machines with two or more address spaces, typically one for 
> instructions and one for data).

Thanks.

> + /* Instruction-space delimited type.  This is for Harvard architectures
> +    which have separate instruction and data address spaces (and perhaps
> +    others).
> + 
> +    GDB usually defines a flat address space that is a superset of the
> +    architecture's two (or more) address spaces, but this is an extension
> +    of the architecture's model.
> + 
> +    If TYPE_FLAG_INST is set, an object of the corresponding type
> +    resides in instruction memory, even if its address (in the extended
> +    flat address space) does not reflect this.
> + 
> +    Similarly, if TYPE_FLAG_DATA is set, then an object of the 
> +    corresponding type resides in the data memory space, even if
> +    this is not indicated by its (flat address space) address.
>   
> +    If neither flag is set, the default space for functions / methods
> +    is instruction space, and for data objects is data memory.  */
> + 
> + #define TYPE_FLAG_CODE_SPACE (1 << 9)
> + #define TYPE_FLAG_DATA_SPACE (1 << 10)

May I suggest that these new macros be added to the docs
gdbint.texinfo?  The large comment tells me they are important enough
to be documented.

Re: [RFC/RFA] gdb extension for Harvard architectures

[Andrew Cagney]

Hmm, that d10v example made me think ...

The d10v has 16 bit code pointers.  They are mapped onto a core addr using:

	((code_ptr) << 2) | 0x01000000)

The key thing being the code pointer has a granularity of 32 bits (aka 4 
bytes).

Given the expression:

	((int32 @code *) func)[1]

I can guess what it does.  However, what about:

	((int16 @code *) func)[1]

I suspect that the proposed model would result in ``[1]'' and ``[0]'' 
being the same location.

Andrew

Re: [RFC/RFA] gdb extension for Harvard architectures

[Jim Blandy]

Andrew Cagney <ac131313@cygnus.com> writes:
> Hmm, that d10v example made me think ...
> 
> The d10v has 16 bit code pointers.  They are mapped onto a core addr using:
> 
> 	((code_ptr) << 2) | 0x01000000)
> 
> The key thing being the code pointer has a granularity of 32 bits (aka 4 
> bytes).
> 
> Given the expression:
> 
> 	((int32 @code *) func)[1]
> 
> I can guess what it does.  However, what about:
> 
> 	((int16 @code *) func)[1]
> 
> I suspect that the proposed model would result in ``[1]'' and ``[0]'' 
> being the same location.

Since GDB represents all pointers into code space the way it does
function pointers, that's right; value_subscript just calls value_add
and then value_ind --- the equivalent of computing *(a+i).  Since
there's no representation for a pointer to the second word of an
instruction, the ADDRESS_TO_POINTER method ends up throwing away the
bits the subscript had affected.

Note that a similar problem occurs already:

    (gdb) print main
    $1 = {int ()} 0x101405c <main>
    (gdb) print main + 1
    $2 = (int (*)()) 0x101405c <main>
    (gdb) print main + 2
    $3 = (int (*)()) 0x101405c <main>
    (gdb) print main + 3
    $4 = (int (*)()) 0x101405c <main>
    (gdb) print main + 4
    $5 = (int (*)()) 0x1014060 <main+4>
    (gdb) 

Note that the first four values are all the same.  If you handed that
expression to x/i, you'd be unhappy.

So this is simply another existing problem, which we don't solve.

Note, however, that our proposal makes it *possible* to solve this
problem in a coherent way.  Since `int16 @code *' values never exist
on the target, GDB can represent them however it likes without
breaking the rule that `GDB always represents values in target form'.
We'd need to add some new logic for arch-dependent conversions between
pointer types, but at least it could be done.