[RFA] Type cleanups

[RFA] Type cleanups

[Daniel Jacobowitz]

In order to fix gdb/277, I needed to move a lot of members of 'struct type'. 
This patch flushes out all (that I could find) direct accesses of these
members instead of through the proper macros.  It's possible that I missed
some; if so, the next patch will cause whichever files I missed to stop
compiling.  I'm pretty sure I got them all, though.  I also clean up the
only remaining references to 'sizeof (struct type)': dstread.c had a clone
of alloc_type, and hpread.c needed to call replace_type like the other
readers.

This patch should have no effect.  On i386-linux, I get byte-for-byte
identical GDB binaries (all 5591185 bytes of it, debugging information
and all; no -g3 here).

OK to commit?

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

2002-05-12  Daniel Jacobowitz  <drow@mvista.com>

	* ax-gdb.c (gen_sign_extend, gen_fetch, gen_usual_unary)
	(gen_cast, gen_scale, gen_add, gen_sub, gen_binop, gen_deref)
	(gen_address_of, gen_struct_ref, gen_repeat): Use type
	access macros.
	* c-typeprint.c (cp_type_print_method_args): Likewise.
	(c_type_print_args): Likewise.
	* d10v-tdep.c (d10v_push_arguments): Likewise.
	(d10v_extract_return_value): Likewise.
	* expprint.c (print_subexp): Likewise.
	* gdbtypes.c (lookup_primitive_typename): Likewise.
	(lookup_template_type, add_mangled_type, print_arg_types): Likewise.
	* gdbtypes.h (TYPE_UNSIGNED, TYPE_NOSIGN, TYPE_STUB)
	(TYPE_TARGET_STUB, TYPE_STATIC, TYPE_CONST, TYPE_VOLATILE)
	(TYPE_PROTOTYPED, TYPE_INCOMPLETE, TYPE_CODE_SPACE, TYPE_VARARGS)
	(TYPE_VECTOR): Likewise.
	* hpread.c (hpread_read_struct_type)
	(fix_static_member_physnames, fixup_class_method_type)
	(hpread_type_lookup): Likewise.
	* mdebugread.c (parse_symbol, parse_type): Likewise.
	* p-lang.c (is_pascal_string_type): Likewise.
	* valops.c (hand_function_call): Likewise.
	* x86-64-tdep.c (classify_argument): Likewise.

	* hpread.c (hpread_read_function_type)
	(hpread_read_doc_function_type): Call replace_type.
	* dstread.c (create_new_type): Delete.
	(decode_dst_structure, process_dst_function): Call alloc_type.
	Use type access macros.

Index: ax-gdb.c
===================================================================
RCS file: /cvs/src/src/gdb/ax-gdb.c,v
retrieving revision 1.12
diff -u -p -r1.12 ax-gdb.c
--- ax-gdb.c	3 Feb 2002 23:11:33 -0000	1.12
+++ ax-gdb.c	13 May 2002 00:04:21 -0000
@@ -353,7 +353,7 @@ gen_sign_extend (struct agent_expr *ax, 
 {
   /* Do we need to sign-extend this?  */
   if (!TYPE_UNSIGNED (type))
-    ax_ext (ax, type->length * TARGET_CHAR_BIT);
+    ax_ext (ax, TYPE_LENGTH (type) * TARGET_CHAR_BIT);
 }
 
 
@@ -363,7 +363,7 @@ gen_sign_extend (struct agent_expr *ax, 
 static void
 gen_extend (struct agent_expr *ax, struct type *type)
 {
-  int bits = type->length * TARGET_CHAR_BIT;
+  int bits = TYPE_LENGTH (type) * TARGET_CHAR_BIT;
   /* I just had to.  */
   ((TYPE_UNSIGNED (type) ? ax_zero_ext : ax_ext) (ax, bits));
 }
@@ -381,7 +381,7 @@ gen_fetch (struct agent_expr *ax, struct
       ax_trace_quick (ax, TYPE_LENGTH (type));
     }
 
-  switch (type->code)
+  switch (TYPE_CODE (type))
     {
     case TYPE_CODE_PTR:
     case TYPE_CODE_ENUM:
@@ -389,7 +389,7 @@ gen_fetch (struct agent_expr *ax, struct
     case TYPE_CODE_CHAR:
       /* It's a scalar value, so we know how to dereference it.  How
          many bytes long is it?  */
-      switch (type->length)
+      switch (TYPE_LENGTH (type))
 	{
 	case 8 / TARGET_CHAR_BIT:
 	  ax_simple (ax, aop_ref8);
@@ -699,7 +699,7 @@ gen_usual_unary (struct agent_expr *ax, 
      the stack.  Should we tweak the type?  */
 
   /* Some types require special handling.  */
-  switch (value->type->code)
+  switch (TYPE_CODE (value->type))
     {
       /* Functions get converted to a pointer to the function.  */
     case TYPE_CODE_FUNC:
@@ -874,7 +874,7 @@ gen_cast (struct agent_expr *ax, struct 
   /* Dereference typedefs. */
   type = check_typedef (type);
 
-  switch (type->code)
+  switch (TYPE_CODE (type))
     {
     case TYPE_CODE_PTR:
       /* It's implementation-defined, and I'll bet this is what GCC
@@ -925,9 +925,9 @@ gen_scale (struct agent_expr *ax, enum a
 {
   struct type *element = TYPE_TARGET_TYPE (type);
 
-  if (element->length != 1)
+  if (TYPE_LENGTH (element) != 1)
     {
-      ax_const_l (ax, element->length);
+      ax_const_l (ax, TYPE_LENGTH (element));
       ax_simple (ax, op);
     }
 }
@@ -943,8 +943,8 @@ gen_add (struct agent_expr *ax, struct a
 	 struct axs_value *value1, struct axs_value *value2, char *name)
 {
   /* Is it INT+PTR?  */
-  if (value1->type->code == TYPE_CODE_INT
-      && value2->type->code == TYPE_CODE_PTR)
+  if (TYPE_CODE (value1->type) == TYPE_CODE_INT
+      && TYPE_CODE (value2->type) == TYPE_CODE_PTR)
     {
       /* Swap the values and proceed normally.  */
       ax_simple (ax, aop_swap);
@@ -955,8 +955,8 @@ gen_add (struct agent_expr *ax, struct a
     }
 
   /* Is it PTR+INT?  */
-  else if (value1->type->code == TYPE_CODE_PTR
-	   && value2->type->code == TYPE_CODE_INT)
+  else if (TYPE_CODE (value1->type) == TYPE_CODE_PTR
+	   && TYPE_CODE (value2->type) == TYPE_CODE_INT)
     {
       gen_scale (ax, aop_mul, value1->type);
       ax_simple (ax, aop_add);
@@ -966,8 +966,8 @@ gen_add (struct agent_expr *ax, struct a
 
   /* Must be number + number; the usual binary conversions will have
      brought them both to the same width.  */
-  else if (value1->type->code == TYPE_CODE_INT
-	   && value2->type->code == TYPE_CODE_INT)
+  else if (TYPE_CODE (value1->type) == TYPE_CODE_INT
+	   && TYPE_CODE (value2->type) == TYPE_CODE_INT)
     {
       ax_simple (ax, aop_add);
       gen_extend (ax, value1->type);	/* Catch overflow.  */
@@ -989,10 +989,10 @@ static void
 gen_sub (struct agent_expr *ax, struct axs_value *value,
 	 struct axs_value *value1, struct axs_value *value2)
 {
-  if (value1->type->code == TYPE_CODE_PTR)
+  if (TYPE_CODE (value1->type) == TYPE_CODE_PTR)
     {
       /* Is it PTR - INT?  */
-      if (value2->type->code == TYPE_CODE_INT)
+      if (TYPE_CODE (value2->type) == TYPE_CODE_INT)
 	{
 	  gen_scale (ax, aop_mul, value1->type);
 	  ax_simple (ax, aop_sub);
@@ -1003,7 +1003,7 @@ gen_sub (struct agent_expr *ax, struct a
       /* Is it PTR - PTR?  Strictly speaking, the types ought to
          match, but this is what the normal GDB expression evaluator
          tests for.  */
-      else if (value2->type->code == TYPE_CODE_PTR
+      else if (TYPE_CODE (value2->type) == TYPE_CODE_PTR
 	       && (TYPE_LENGTH (TYPE_TARGET_TYPE (value1->type))
 		   == TYPE_LENGTH (TYPE_TARGET_TYPE (value2->type))))
 	{
@@ -1018,8 +1018,8 @@ an integer nor a pointer of the same typ
     }
 
   /* Must be number + number.  */
-  else if (value1->type->code == TYPE_CODE_INT
-	   && value2->type->code == TYPE_CODE_INT)
+  else if (TYPE_CODE (value1->type) == TYPE_CODE_INT
+	   && TYPE_CODE (value2->type) == TYPE_CODE_INT)
     {
       ax_simple (ax, aop_sub);
       gen_extend (ax, value1->type);	/* Catch overflow.  */
@@ -1044,8 +1044,8 @@ gen_binop (struct agent_expr *ax, struct
 	   enum agent_op op_unsigned, int may_carry, char *name)
 {
   /* We only handle INT op INT.  */
-  if ((value1->type->code != TYPE_CODE_INT)
-      || (value2->type->code != TYPE_CODE_INT))
+  if ((TYPE_CODE (value1->type) != TYPE_CODE_INT)
+      || (TYPE_CODE (value2->type) != TYPE_CODE_INT))
     error ("Illegal combination of types in %s.", name);
 
   ax_simple (ax,
@@ -1092,7 +1092,7 @@ gen_deref (struct agent_expr *ax, struct
 {
   /* The caller should check the type, because several operators use
      this, and we don't know what error message to generate.  */
-  if (value->type->code != TYPE_CODE_PTR)
+  if (TYPE_CODE (value->type) != TYPE_CODE_PTR)
     internal_error (__FILE__, __LINE__,
 		    "gen_deref: expected a pointer");
 
@@ -1102,7 +1102,7 @@ gen_deref (struct agent_expr *ax, struct
      T" to "T", and mark the value as an lvalue in memory.  Leave it
      to the consumer to actually dereference it.  */
   value->type = check_typedef (TYPE_TARGET_TYPE (value->type));
-  value->kind = ((value->type->code == TYPE_CODE_FUNC)
+  value->kind = ((TYPE_CODE (value->type) == TYPE_CODE_FUNC)
 		 ? axs_rvalue : axs_lvalue_memory);
 }
 
@@ -1114,7 +1114,7 @@ gen_address_of (struct agent_expr *ax, s
   /* Special case for taking the address of a function.  The ANSI
      standard describes this as a special case, too, so this
      arrangement is not without motivation.  */
-  if (value->type->code == TYPE_CODE_FUNC)
+  if (TYPE_CODE (value->type) == TYPE_CODE_FUNC)
     /* The value's already an rvalue on the stack, so we just need to
        change the type.  */
     value->type = lookup_pointer_type (value->type);
@@ -1346,7 +1346,7 @@ gen_struct_ref (struct agent_expr *ax, s
   /* Follow pointers until we reach a non-pointer.  These aren't the C
      semantics, but they're what the normal GDB evaluator does, so we
      should at least be consistent.  */
-  while (value->type->code == TYPE_CODE_PTR)
+  while (TYPE_CODE (value->type) == TYPE_CODE_PTR)
     {
       gen_usual_unary (ax, value);
       gen_deref (ax, value);
@@ -1410,7 +1410,7 @@ gen_repeat (union exp_element **pc, stru
 
     if (!v)
       error ("Right operand of `@' must be a constant, in agent expressions.");
-    if (v->type->code != TYPE_CODE_INT)
+    if (TYPE_CODE (v->type) != TYPE_CODE_INT)
       error ("Right operand of `@' must be an integer.");
     length = value_as_long (v);
     if (length <= 0)
Index: c-typeprint.c
===================================================================
RCS file: /cvs/src/src/gdb/c-typeprint.c,v
retrieving revision 1.18
diff -u -p -r1.18 c-typeprint.c
--- c-typeprint.c	9 Feb 2002 16:08:53 -0000	1.18
+++ c-typeprint.c	13 May 2002 00:04:21 -0000
@@ -158,7 +158,7 @@ cp_type_print_method_args (struct type *
   fprintf_symbol_filtered (stream, prefix, language_cplus, DMGL_ANSI);
   fprintf_symbol_filtered (stream, varstring, language_cplus, DMGL_ANSI);
   fputs_filtered ("(", stream);
-  if (args && args[!staticp] && args[!staticp]->code != TYPE_CODE_VOID)
+  if (args && args[!staticp] && TYPE_CODE (args[!staticp]) != TYPE_CODE_VOID)
     {
       i = !staticp;		/* skip the class variable */
       while (1)
@@ -169,7 +169,7 @@ cp_type_print_method_args (struct type *
 	      fprintf_filtered (stream, " ...");
 	      break;
 	    }
-	  else if (args[i]->code != TYPE_CODE_VOID)
+	  else if (TYPE_CODE (args[i]) != TYPE_CODE_VOID)
 	    {
 	      fprintf_filtered (stream, ", ");
 	    }
@@ -346,7 +346,7 @@ c_type_print_args (struct type *type, st
 	{
 	  fprintf_filtered (stream, "...");
 	}
-      else if ((args[1]->code == TYPE_CODE_VOID) &&
+      else if ((TYPE_CODE (args[1]) == TYPE_CODE_VOID) &&
 	       (current_language->la_language == language_cplus))
 	{
 	  fprintf_filtered (stream, "void");
@@ -354,7 +354,7 @@ c_type_print_args (struct type *type, st
       else
 	{
 	  for (i = 1;
-	       args[i] != NULL && args[i]->code != TYPE_CODE_VOID;
+	       args[i] != NULL && TYPE_CODE (args[i]) != TYPE_CODE_VOID;
 	       i++)
 	    {
 	      c_print_type (args[i], "", stream, -1, 0);
@@ -362,7 +362,7 @@ c_type_print_args (struct type *type, st
 		{
 		  fprintf_filtered (stream, "...");
 		}
-	      else if (args[i + 1]->code != TYPE_CODE_VOID)
+	      else if (TYPE_CODE (args[i + 1]) != TYPE_CODE_VOID)
 		{
 		  fprintf_filtered (stream, ",");
 		  wrap_here ("    ");
Index: d10v-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/d10v-tdep.c,v
retrieving revision 1.38
diff -u -p -r1.38 d10v-tdep.c
--- d10v-tdep.c	12 May 2002 02:16:03 -0000	1.38
+++ d10v-tdep.c	13 May 2002 00:04:22 -0000
@@ -1037,7 +1037,7 @@ d10v_push_arguments (int nargs, struct v
       struct type *type = check_typedef (VALUE_TYPE (arg));
       char *contents = VALUE_CONTENTS (arg);
       int len = TYPE_LENGTH (type);
-      /* printf ("push: type=%d len=%d\n", type->code, len); */
+      /* printf ("push: type=%d len=%d\n", TYPE_CODE (type), len); */
 	{
 	  int aligned_regnum = (regnum + 1) & ~1;
 	  if (len <= 2 && regnum <= ARGN_REGNUM)
@@ -1091,7 +1091,7 @@ d10v_extract_return_value (struct type *
 			   char *valbuf)
 {
   int len;
-  /*    printf("RET: TYPE=%d len=%d r%d=0x%x\n",type->code, TYPE_LENGTH (type), RET1_REGNUM - R0_REGNUM, (int) extract_unsigned_integer (regbuf + REGISTER_BYTE(RET1_REGNUM), REGISTER_RAW_SIZE (RET1_REGNUM)));  */
+  /*    printf("RET: TYPE=%d len=%d r%d=0x%x\n", TYPE_CODE (type), TYPE_LENGTH (type), RET1_REGNUM - R0_REGNUM, (int) extract_unsigned_integer (regbuf + REGISTER_BYTE(RET1_REGNUM), REGISTER_RAW_SIZE (RET1_REGNUM)));  */
     {
       len = TYPE_LENGTH (type);
       if (len == 1)
Index: dstread.c
===================================================================
RCS file: /cvs/src/src/gdb/dstread.c,v
retrieving revision 1.7
diff -u -p -r1.7 dstread.c
--- dstread.c	6 Mar 2001 08:21:06 -0000	1.7
+++ dstread.c	13 May 2002 00:04:24 -0000
@@ -705,17 +705,6 @@ dst_sym_addr (dst_sect_ref_t *ref)
     + ref->sect_offset;
 }
 
-static struct type *
-create_new_type (struct objfile *objfile)
-{
-  struct type *type;
-
-  type = (struct type *)
-    obstack_alloc (&objfile->symbol_obstack, sizeof (struct type));
-  memset (type, 0, sizeof (struct type));
-  return type;
-}
-
 static struct symbol *
 create_new_symbol (struct objfile *objfile, char *name)
 {
@@ -865,7 +854,7 @@ decode_dst_structure (struct objfile *ob
       xfree (name);
       return type;
     }
-  type = create_new_type (objfile);
+  type = alloc_type (objfile);
   TYPE_NAME (type) = obstack_copy0 (&objfile->symbol_obstack,
 				    name, strlen (name));
   xfree (name);
@@ -1306,10 +1295,10 @@ process_dst_function (struct objfile *ob
 
   if (!type->function_type)
     {
-      ftype = create_new_type (objfile);
+      ftype = alloc_type (objfile);
       type->function_type = ftype;
-      ftype->target_type = type;
-      ftype->code = TYPE_CODE_FUNC;
+      TYPE_TARGET_TYPE (ftype) = type;
+      TYPE_CODE (ftype) = TYPE_CODE_FUNC;
     }
   SYMBOL_TYPE (sym) = type->function_type;
 
Index: expprint.c
===================================================================
RCS file: /cvs/src/src/gdb/expprint.c,v
retrieving revision 1.6
diff -u -p -r1.6 expprint.c
--- expprint.c	10 Nov 2001 21:34:55 -0000	1.6
+++ expprint.c	13 May 2002 00:04:26 -0000
@@ -334,7 +334,7 @@ print_subexp (register struct expression
       (*pos) += 2;
       if ((int) prec > (int) PREC_PREFIX)
 	fputs_filtered ("(", stream);
-      if (exp->elts[pc + 1].type->code == TYPE_CODE_FUNC &&
+      if (TYPE_CODE (exp->elts[pc + 1].type) == TYPE_CODE_FUNC &&
 	  exp->elts[pc + 3].opcode == OP_LONG)
 	{
 	  /* We have a minimal symbol fn, probably.  It's encoded
Index: gdbtypes.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.c,v
retrieving revision 1.49
diff -u -p -r1.49 gdbtypes.c
--- gdbtypes.c	12 May 2002 02:20:38 -0000	1.49
+++ gdbtypes.c	13 May 2002 00:04:27 -0000
@@ -936,7 +910,7 @@ lookup_primitive_typename (char *name)
 
   for (p = current_language->la_builtin_type_vector; *p != NULL; p++)
     {
-      if (STREQ ((**p)->name, name))
+      if (STREQ (TYPE_NAME (**p), name))
 	{
 	  return (**p);
 	}
@@ -1081,10 +1055,10 @@ struct type *
 lookup_template_type (char *name, struct type *type, struct block *block)
 {
   struct symbol *sym;
-  char *nam = (char *) alloca (strlen (name) + strlen (type->name) + 4);
+  char *nam = (char *) alloca (strlen (name) + strlen (TYPE_NAME (type)) + 4);
   strcpy (nam, name);
   strcat (nam, "<");
-  strcat (nam, type->name);
+  strcat (nam, TYPE_NAME (type));
   strcat (nam, " >");		/* FIXME, extra space still introduced in gcc? */
 
   sym = lookup_symbol (nam, block, VAR_NAMESPACE, 0, (struct symtab **) NULL);
@@ -1511,8 +1485,8 @@ add_mangled_type (struct extra *pextras,
 	complain (&msg, tcode);
       }
     }
-  if (t->target_type)
-    add_mangled_type (pextras, t->target_type);
+  if (TYPE_TARGET_TYPE (t))
+    add_mangled_type (pextras, TYPE_TARGET_TYPE (t));
 }
 
 #if 0
@@ -2713,7 +2687,7 @@ print_arg_types (struct type **args, int
       while (*args != NULL)
 	{
 	  recursive_dump_type (*args, spaces + 2);
-	  if ((*args++)->code == TYPE_CODE_VOID)
+	  if (TYPE_CODE (*args++) == TYPE_CODE_VOID)
 	    {
 	      break;
 	    }
Index: gdbtypes.h
===================================================================
RCS file: /cvs/src/src/gdb/gdbtypes.h,v
retrieving revision 1.28
diff -u -p -r1.28 gdbtypes.h
--- gdbtypes.h	26 Apr 2002 20:08:18 -0000	1.28
+++ gdbtypes.h	13 May 2002 00:04:30 -0000
@@ -148,21 +148,21 @@ enum type_code
    type is signed (unless TYPE_FLAG_NOSIGN (below) is set). */
 
 #define TYPE_FLAG_UNSIGNED	(1 << 0)
-#define TYPE_UNSIGNED(t)	((t)->flags & TYPE_FLAG_UNSIGNED)
+#define TYPE_UNSIGNED(t)	(TYPE_FLAGS (t) & TYPE_FLAG_UNSIGNED)
 
 /* No sign for this type.  In C++, "char", "signed char", and "unsigned
    char" are distinct types; so we need an extra flag to indicate the
    absence of a sign! */
 
 #define TYPE_FLAG_NOSIGN	(1 << 1)
-#define TYPE_NOSIGN(t)		((t)->flags & TYPE_FLAG_NOSIGN)
+#define TYPE_NOSIGN(t)		(TYPE_FLAGS (t) & TYPE_FLAG_NOSIGN)
 
 /* This appears in a type's flags word if it is a stub type (e.g., if
    someone referenced a type that wasn't defined in a source file
    via (struct sir_not_appearing_in_this_film *)).  */
 
 #define TYPE_FLAG_STUB		(1 << 2)
-#define TYPE_STUB(t)		((t)->flags & TYPE_FLAG_STUB)
+#define TYPE_STUB(t)		(TYPE_FLAGS (t) & TYPE_FLAG_STUB)
 
 /* The target type of this type is a stub type, and this type needs to
    be updated if it gets un-stubbed in check_typedef.
@@ -171,7 +171,7 @@ enum type_code
    Also, set for TYPE_CODE_TYPEDEF. */
 
 #define TYPE_FLAG_TARGET_STUB	(1 << 3)
-#define TYPE_TARGET_STUB(t)	((t)->flags & TYPE_FLAG_TARGET_STUB)
+#define TYPE_TARGET_STUB(t)	(TYPE_FLAGS (t) & TYPE_FLAG_TARGET_STUB)
 
 /* Static type.  If this is set, the corresponding type had 
  * a static modifier.
@@ -180,21 +180,21 @@ enum type_code
  */
 
 #define TYPE_FLAG_STATIC	(1 << 4)
-#define TYPE_STATIC(t)		((t)->flags & TYPE_FLAG_STATIC)
+#define TYPE_STATIC(t)		(TYPE_FLAGS (t) & TYPE_FLAG_STATIC)
 
 /* Constant type.  If this is set, the corresponding type has a
  * const modifier.
  */
 
 #define TYPE_FLAG_CONST		(1 << 5)
-#define TYPE_CONST(t)		((t)->flags & TYPE_FLAG_CONST)
+#define TYPE_CONST(t)		(TYPE_FLAGS (t) & TYPE_FLAG_CONST)
 
 /* Volatile type.  If this is set, the corresponding type has a
  * volatile modifier.
  */
 
 #define TYPE_FLAG_VOLATILE	(1 << 6)
-#define TYPE_VOLATILE(t)	((t)->flags & TYPE_FLAG_VOLATILE)
+#define TYPE_VOLATILE(t)	(TYPE_FLAGS (t) & TYPE_FLAG_VOLATILE)
 
 
 /* This is a function type which appears to have a prototype.  We need this
@@ -202,7 +202,7 @@ enum type_code
    or to just do the standard conversions.  This is used with a short field. */
 
 #define TYPE_FLAG_PROTOTYPED	(1 << 7)
-#define TYPE_PROTOTYPED(t)	((t)->flags & TYPE_FLAG_PROTOTYPED)
+#define TYPE_PROTOTYPED(t)	(TYPE_FLAGS (t) & TYPE_FLAG_PROTOTYPED)
 
 /* This flag is used to indicate that processing for this type
    is incomplete.
@@ -213,7 +213,7 @@ enum type_code
    the method can be assigned correct types.) */
 
 #define TYPE_FLAG_INCOMPLETE	(1 << 8)
-#define TYPE_INCOMPLETE(t)	((t)->flags & TYPE_FLAG_INCOMPLETE)
+#define TYPE_INCOMPLETE(t)	(TYPE_FLAGS (t) & TYPE_FLAG_INCOMPLETE)
 
 /* Instruction-space delimited type.  This is for Harvard architectures
    which have separate instruction and data address spaces (and perhaps
@@ -235,10 +235,10 @@ enum type_code
    is instruction space, and for data objects is data memory.  */
 
 #define TYPE_FLAG_CODE_SPACE	(1 << 9)
-#define TYPE_CODE_SPACE(t)	((t)->flags & TYPE_FLAG_CODE_SPACE)
+#define TYPE_CODE_SPACE(t)	(TYPE_FLAGS (t) & TYPE_FLAG_CODE_SPACE)
 
 #define TYPE_FLAG_DATA_SPACE	(1 << 10)
-#define TYPE_DATA_SPACE(t)	((t)->flags & TYPE_FLAG_DATA_SPACE)
+#define TYPE_DATA_SPACE(t)	(TYPE_FLAGS (t) & TYPE_FLAG_DATA_SPACE)
 
 /* FIXME: Kludge to mark a varargs function type for C++ member
    function argument processing.  Currently only used in dwarf2read.c,
@@ -246,11 +246,11 @@ enum type_code
    another flag.  */
 
 #define TYPE_FLAG_VARARGS	(1 << 11)
-#define TYPE_VARARGS(t)		((t)->flags & TYPE_FLAG_VARARGS)
+#define TYPE_VARARGS(t)		(TYPE_FLAGS (t) & TYPE_FLAG_VARARGS)
 
 /* Identify a vector type.  Gcc is handling this by adding an extra
    attribute to the array type.  We slurp that in as a new flag of a
    type.  This is used only in dwarf2read.c.  */
 #define TYPE_FLAG_VECTOR	(1 << 12)
-#define TYPE_VECTOR(t)		((t)->flags & TYPE_FLAG_VECTOR)
+#define TYPE_VECTOR(t)		(TYPE_FLAGS (t) & TYPE_FLAG_VECTOR)
 
Index: hpread.c
===================================================================
RCS file: /cvs/src/src/gdb/hpread.c,v
retrieving revision 1.17
diff -u -p -r1.17 hpread.c
--- hpread.c	30 Apr 2002 02:06:25 -0000	1.17
+++ hpread.c	13 May 2002 00:04:35 -0000
@@ -3230,7 +3230,7 @@ hpread_read_function_type (dnttpointer h
       else			/* expect DNTT_TYPE_FUNC_TEMPLATE */
 	type1 = lookup_function_type (hpread_type_lookup (dn_bufp->dfunc_template.retval,
 							  objfile));
-      memcpy ((char *) type, (char *) type1, sizeof (struct type));
+      replace_type (type, type1);
 
       /* Mark it -- in the middle of processing */
       TYPE_FLAGS (type) |= TYPE_FLAG_INCOMPLETE;
@@ -3407,7 +3407,7 @@ hpread_read_doc_function_type (dnttpoint
 	  dn_bufp->dblock.kind == DNTT_TYPE_DOC_MEMFUNC)
 	type1 = lookup_function_type (hpread_type_lookup (dn_bufp->ddocfunc.retval,
 							  objfile));
-      memcpy ((char *) type, (char *) type1, sizeof (struct type));
+      replace_type (type, type1);
 
       /* Mark it -- in the middle of processing */
       TYPE_FLAGS (type) |= TYPE_FLAG_INCOMPLETE;
@@ -3968,23 +3968,28 @@ hpread_read_struct_type (dnttpointer hp_
 		  fn_p->field.fn_fields[ix].type = memtype;
 
 		  /* The argument list */
-		  fn_p->field.fn_fields[ix].type->type_specific.arg_types =
-		    (struct type **) obstack_alloc (&objfile->type_obstack,
-			   sizeof (struct type *) * (memtype->nfields + 1));
-		  for (i = 0; i < memtype->nfields; i++)
-		    fn_p->field.fn_fields[ix].type->type_specific.arg_types[i] = memtype->fields[i].type;
+		  TYPE_TYPE_SPECIFIC (fn_p->field.fn_fields[ix].type).arg_types
+		    = (struct type **) obstack_alloc (&objfile->type_obstack,
+						      (sizeof (struct type *)
+						       * (TYPE_NFIELDS (memtype)
+							  + 1)));
+		  for (i = 0; i < TYPE_NFIELDS (memtype); i++)
+		    TYPE_TYPE_SPECIFIC (fn_p->field.fn_fields[ix].type)
+		      .arg_types[i] = TYPE_FIELDS (memtype)[i].type;
 		  /* void termination */
-		  fn_p->field.fn_fields[ix].type->type_specific.arg_types[memtype->nfields] = builtin_type_void;
+		  TYPE_TYPE_SPECIFIC (fn_p->field.fn_fields[ix].type)
+		    .arg_types[TYPE_NFIELDS (memtype)] = builtin_type_void;
 
 		  /* pai: It's not clear why this args field has to be set.  Perhaps
 		   * it should be eliminated entirely. */
 		  fn_p->field.fn_fields[ix].args =
 		    (struct type **) obstack_alloc (&objfile->type_obstack,
-			   sizeof (struct type *) * (memtype->nfields + 1));
-		  for (i = 0; i < memtype->nfields; i++)
-		    fn_p->field.fn_fields[ix].args[i] = memtype->fields[i].type;
+			   sizeof (struct type *) * (TYPE_NFIELDS (memtype) + 1));
+		  for (i = 0; i < TYPE_NFIELDS (memtype); i++)
+		    fn_p->field.fn_fields[ix].args[i]
+		      = TYPE_FIELDS (memtype)[i].type;
 		  /* null-terminated, unlike arg_types above e */
-		  fn_p->field.fn_fields[ix].args[memtype->nfields] = NULL;
+		  fn_p->field.fn_fields[ix].args[TYPE_NFIELDS (memtype)] = NULL;
 		}
 	      /* For virtual functions, fill in the voffset field with the
 	       * virtual table offset. (This is just copied over from the
@@ -4428,7 +4430,7 @@ fix_static_member_physnames (struct type
 	if (TYPE_FIELD_STATIC_PHYSNAME (type, i))
 	  return;		/* physnames are already set */
 
-	SET_FIELD_PHYSNAME (type->fields[i],
+	SET_FIELD_PHYSNAME (TYPE_FIELDS (type)[i],
 			    obstack_alloc (&objfile->type_obstack,
 	     strlen (class_name) + strlen (TYPE_FIELD_NAME (type, i)) + 3));
 	strcpy (TYPE_FIELD_STATIC_PHYSNAME (type, i), class_name);
@@ -4465,23 +4467,23 @@ fixup_class_method_type (struct type *cl
 	  /* Set the method type */
 	  TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j) = method;
 	  /* The argument list */
-	  (TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j))->type_specific.arg_types
+	  TYPE_TYPE_SPECIFIC (TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j)).arg_types
 	    = (struct type **) obstack_alloc (&objfile->type_obstack,
-			    sizeof (struct type *) * (method->nfields + 1));
-	  for (k = 0; k < method->nfields; k++)
-	    (TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j))->type_specific.arg_types[k] = method->fields[k].type;
+			    sizeof (struct type *) * (TYPE_NFIELDS (method) + 1));
+	  for (k = 0; k < TYPE_NFIELDS (method); k++)
+	    TYPE_TYPE_SPECIFIC (TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j)).arg_types[k] = TYPE_FIELDS (method)[k].type;
 	  /* void termination */
-	  (TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j))->type_specific.arg_types[method->nfields] = builtin_type_void;
+	  TYPE_TYPE_SPECIFIC (TYPE_FN_FIELD_TYPE (TYPE_FN_FIELDLIST1 (class, i), j)).arg_types[TYPE_NFIELDS (method)] = builtin_type_void;
 
 	  /* pai: It's not clear why this args field has to be set.  Perhaps
 	   * it should be eliminated entirely. */
 	  (TYPE_FN_FIELD (TYPE_FN_FIELDLIST1 (class, i), j)).args
 	    = (struct type **) obstack_alloc (&objfile->type_obstack,
-			    sizeof (struct type *) * (method->nfields + 1));
-	  for (k = 0; k < method->nfields; k++)
-	    (TYPE_FN_FIELD (TYPE_FN_FIELDLIST1 (class, i), j)).args[k] = method->fields[k].type;
+			    sizeof (struct type *) * (TYPE_NFIELDS (method) + 1));
+	  for (k = 0; k < TYPE_NFIELDS (method); k++)
+	    (TYPE_FN_FIELD (TYPE_FN_FIELDLIST1 (class, i), j)).args[k] = TYPE_FIELDS (method)[k].type;
 	  /* null-terminated, unlike arg_types above */
-	  (TYPE_FN_FIELD (TYPE_FN_FIELDLIST1 (class, i), j)).args[method->nfields] = NULL;
+	  (TYPE_FN_FIELD (TYPE_FN_FIELDLIST1 (class, i), j)).args[TYPE_NFIELDS (method)] = NULL;
 
 	  /* Break out of both loops -- only one method to fix up in a class */
 	  goto finish;
@@ -4850,7 +4852,7 @@ hpread_type_lookup (dnttpointer hp_type,
 	  }
 
 	/* Build the correct name.  */
-	structtype->name
+	TYPE_NAME (structtype)
 	  = (char *) obstack_alloc (&objfile->type_obstack,
 				    strlen (prefix) + strlen (suffix) + 1);
 	TYPE_NAME (structtype) = strcpy (TYPE_NAME (structtype), prefix);
Index: mdebugread.c
===================================================================
RCS file: /cvs/src/src/gdb/mdebugread.c,v
retrieving revision 1.25
diff -u -p -r1.25 mdebugread.c
--- mdebugread.c	22 Apr 2002 10:19:35 -0000	1.25
+++ mdebugread.c	13 May 2002 00:04:38 -0000
@@ -832,7 +832,7 @@ parse_symbol (SYMR *sh, union aux_ext *a
       else
 	{
 	  t = parse_type (cur_fd, ax, sh->index + 1, 0, bigend, name);
-	  if (STREQ (name, "malloc") && t->code == TYPE_CODE_VOID)
+	  if (STREQ (name, "malloc") && TYPE_CODE (t) == TYPE_CODE_VOID)
 	    {
 	      /* I don't know why, but, at least under Alpha GNU/Linux,
 	         when linking against a malloc without debugging
@@ -1604,7 +1604,7 @@ parse_type (int fd, union aux_ext *ax, u
          dereference them.  */
       while (TYPE_CODE (tp) == TYPE_CODE_PTR
 	     || TYPE_CODE (tp) == TYPE_CODE_ARRAY)
-	tp = tp->target_type;
+	tp = TYPE_TARGET_TYPE (tp);
 
       /* Make sure that TYPE_CODE(tp) has an expected type code.
          Any type may be returned from cross_ref if file indirect entries
Index: p-lang.c
===================================================================
RCS file: /cvs/src/src/gdb/p-lang.c,v
retrieving revision 1.7
diff -u -p -r1.7 p-lang.c
--- p-lang.c	2 May 2002 11:26:01 -0000	1.7
+++ p-lang.c	13 May 2002 00:04:38 -0000
@@ -58,7 +58,7 @@ is_pascal_string_type (struct type *type
           if (length_pos)
 	    *length_pos = TYPE_FIELD_BITPOS (type, 0) / TARGET_CHAR_BIT;
           if (length_size)
-	    *length_size = TYPE_FIELD_TYPE (type, 0)->length;
+	    *length_size = TYPE_LENGTH (TYPE_FIELD_TYPE (type, 0));
           if (string_pos)
 	    *string_pos = TYPE_FIELD_BITPOS (type, 1) / TARGET_CHAR_BIT;
           if (char_size)
@@ -76,7 +76,7 @@ is_pascal_string_type (struct type *type
           if (length_pos)
 	    *length_pos = TYPE_FIELD_BITPOS (type, 1) / TARGET_CHAR_BIT;
           if (length_size)
-	    *length_size = TYPE_FIELD_TYPE (type, 1)->length;
+	    *length_size = TYPE_LENGTH (TYPE_FIELD_TYPE (type, 1));
           if (string_pos)
 	    *string_pos = TYPE_FIELD_BITPOS (type, 2) / TARGET_CHAR_BIT;
           /* FIXME: how can I detect wide chars in GPC ?? */
Index: valops.c
===================================================================
RCS file: /cvs/src/src/gdb/valops.c,v
retrieving revision 1.58
diff -u -p -r1.58 valops.c
--- valops.c	12 May 2002 03:09:12 -0000	1.58
+++ valops.c	13 May 2002 00:04:47 -0000
@@ -1488,7 +1488,7 @@ hand_function_call (struct value *functi
 	if (param_type)
 	  /* if this parameter is a pointer to function */
 	  if (TYPE_CODE (param_type) == TYPE_CODE_PTR)
-	    if (TYPE_CODE (param_type->target_type) == TYPE_CODE_FUNC)
+	    if (TYPE_CODE (TYPE_TARGET_TYPE (param_type)) == TYPE_CODE_FUNC)
 	      /* elz: FIXME here should go the test about the compiler used
 	         to compile the target. We want to issue the error
 	         message only if the compiler used was HP's aCC.
Index: x86-64-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/x86-64-tdep.c,v
retrieving revision 1.18
diff -u -p -r1.18 x86-64-tdep.c
--- x86-64-tdep.c	12 May 2002 02:16:04 -0000	1.18
+++ x86-64-tdep.c	13 May 2002 00:04:47 -0000
@@ -372,18 +372,18 @@ classify_argument (struct type *type,
 	  case TYPE_CODE_STRUCT:
 	    {
 	      int j;
-	      for (j = 0; j < type->nfields; ++j)
+	      for (j = 0; j < TYPE_NFIELDS (type); ++j)
 		{
-		  int num = classify_argument (type->fields[j].type,
+		  int num = classify_argument (TYPE_FIELDS (type)[j].type,
 					       subclasses,
-					       (type->fields[j].loc.bitpos
+					       (TYPE_FIELDS (type)[j].loc.bitpos
 						+ bit_offset) % 256);
 		  if (!num)
 		    return 0;
 		  for (i = 0; i < num; i++)
 		    {
 		      int pos =
-			(type->fields[j].loc.bitpos + bit_offset) / 8 / 8;
+			(TYPE_FIELDS (type)[j].loc.bitpos + bit_offset) / 8 / 8;
 		      classes[i + pos] =
 			merge_classes (subclasses[i], classes[i + pos]);
 		    }
@@ -394,7 +394,7 @@ classify_argument (struct type *type,
 	    {
 	      int num;
 
-	      num = classify_argument (type->target_type,
+	      num = classify_argument (TYPE_TARGET_TYPE (type),
 				       subclasses, bit_offset);
 	      if (!num)
 		return 0;
@@ -413,10 +413,10 @@ classify_argument (struct type *type,
 	    {
 	      int j;
 	      {
-		for (j = 0; j < type->nfields; ++j)
+		for (j = 0; j < TYPE_NFIELDS (type); ++j)
 		  {
 		    int num;
-		    num = classify_argument (type->fields[j].type,
+		    num = classify_argument (TYPE_FIELDS (type)[j].type,
 					     subclasses, bit_offset);
 		    if (!num)
 		      return 0;

Re: [RFA] Type cleanups

[Andrew Cagney]

> In order to fix gdb/277, I needed to move a lot of members of 'struct type'. 
> This patch flushes out all (that I could find) direct accesses of these
> members instead of through the proper macros.  It's possible that I missed
> some; if so, the next patch will cause whichever files I missed to stop
> compiling.  I'm pretty sure I got them all, though.  I also clean up the
> only remaining references to 'sizeof (struct type)': dstread.c had a clone
> of alloc_type, and hpread.c needed to call replace_type like the other
> readers.
> 
> This patch should have no effect.  On i386-linux, I get byte-for-byte
> identical GDB binaries (all 5591185 bytes of it, debugging information
> and all; no -g3 here).
> 
> OK to commit?

Did you check all the cross targets build per MAINTAINERS?  From memory 
sh-hms[bfd] and avr[need to look] don't build at present (well as of 
~2002-05-12-gmt).

If that has been checked, then yes ``obviously''.

Does this mean that ``struct type *'' is becoming opaque?  Looking at 
the next patch, no, sigh.

Andrew



> 2002-05-12  Daniel Jacobowitz  <drow@mvista.com>
> 
> 	* ax-gdb.c (gen_sign_extend, gen_fetch, gen_usual_unary)
> 	(gen_cast, gen_scale, gen_add, gen_sub, gen_binop, gen_deref)
> 	(gen_address_of, gen_struct_ref, gen_repeat): Use type
> 	access macros.
> 	* c-typeprint.c (cp_type_print_method_args): Likewise.
> 	(c_type_print_args): Likewise.
> 	* d10v-tdep.c (d10v_push_arguments): Likewise.
> 	(d10v_extract_return_value): Likewise.
> 	* expprint.c (print_subexp): Likewise.
> 	* gdbtypes.c (lookup_primitive_typename): Likewise.
> 	(lookup_template_type, add_mangled_type, print_arg_types): Likewise.
> 	* gdbtypes.h (TYPE_UNSIGNED, TYPE_NOSIGN, TYPE_STUB)
> 	(TYPE_TARGET_STUB, TYPE_STATIC, TYPE_CONST, TYPE_VOLATILE)
> 	(TYPE_PROTOTYPED, TYPE_INCOMPLETE, TYPE_CODE_SPACE, TYPE_VARARGS)
> 	(TYPE_VECTOR): Likewise.
> 	* hpread.c (hpread_read_struct_type)
> 	(fix_static_member_physnames, fixup_class_method_type)
> 	(hpread_type_lookup): Likewise.
> 	* mdebugread.c (parse_symbol, parse_type): Likewise.
> 	* p-lang.c (is_pascal_string_type): Likewise.
> 	* valops.c (hand_function_call): Likewise.
> 	* x86-64-tdep.c (classify_argument): Likewise.
> 
> 	* hpread.c (hpread_read_function_type)
> 	(hpread_read_doc_function_type): Call replace_type.
> 	* dstread.c (create_new_type): Delete.
> 	(decode_dst_structure, process_dst_function): Call alloc_type.
> 	Use type access macros.

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Sun, May 12, 2002 at 11:18:25PM -0400, Andrew Cagney wrote:
> >In order to fix gdb/277, I needed to move a lot of members of 'struct 
> >type'. This patch flushes out all (that I could find) direct accesses of 
> >these
> >members instead of through the proper macros.  It's possible that I missed
> >some; if so, the next patch will cause whichever files I missed to stop
> >compiling.  I'm pretty sure I got them all, though.  I also clean up the
> >only remaining references to 'sizeof (struct type)': dstread.c had a clone
> >of alloc_type, and hpread.c needed to call replace_type like the other
> >readers.
> >
> >This patch should have no effect.  On i386-linux, I get byte-for-byte
> >identical GDB binaries (all 5591185 bytes of it, debugging information
> >and all; no -g3 here).
> >
> >OK to commit?
> 
> Did you check all the cross targets build per MAINTAINERS?  From memory 
> sh-hms[bfd] and avr[need to look] don't build at present (well as of 
> ~2002-05-12-gmt).
> 
> If that has been checked, then yes ``obviously''.

I'll do that.  Sigh, takes forever... least there are scripts for it.

BTW, the fragment of awk in MAINTAINERS only works with GNU awk.

> Does this mean that ``struct type *'' is becoming opaque?  Looking at 
> the next patch, no, sigh.

No.  It's accessed so frequently that switching from macros to accessor
functions would be a ridiculous performance hit, I think.

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

Re: [RFA] Type cleanups

[Andrew Cagney]

> Does this mean that ``struct type *'' is becoming opaque?  Looking at 
>> the next patch, no, sigh.
> 
> 
> No.  It's accessed so frequently that switching from macros to accessor
> functions would be a ridiculous performance hit, I think.

The last time this came up, the consensus was that a macro should be 
converted to a function, even when it resulted in a performance loss 
(things were a bit vague on how much).  The debate was about STREQ which 
is in the critical path for symbol table reading and the like.

Anyway, I tend to look at it more pragmatically.  Is my (your, and other 
developers) time best spent chasing after people that forget to or 
wrongly use the accessor macro, or, on fixing real problems.  Given that 
I'm struggling to show a performance gain from a frame based register 
cache, and no one has noticed me adding another assertion to every 
gdbarch accessor function, I don't expect changing the above to opaque 
to be a significant problem :-)

enjoy,
Andrew

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Sun, May 12, 2002 at 11:18:25PM -0400, Andrew Cagney wrote:
> >In order to fix gdb/277, I needed to move a lot of members of 'struct 
> >type'. This patch flushes out all (that I could find) direct accesses of 
> >these
> >members instead of through the proper macros.  It's possible that I missed
> >some; if so, the next patch will cause whichever files I missed to stop
> >compiling.  I'm pretty sure I got them all, though.  I also clean up the
> >only remaining references to 'sizeof (struct type)': dstread.c had a clone
> >of alloc_type, and hpread.c needed to call replace_type like the other
> >readers.
> >
> >This patch should have no effect.  On i386-linux, I get byte-for-byte
> >identical GDB binaries (all 5591185 bytes of it, debugging information
> >and all; no -g3 here).
> >
> >OK to commit?
> 
> Did you check all the cross targets build per MAINTAINERS?  From memory 
> sh-hms[bfd] and avr[need to look] don't build at present (well as of 
> ~2002-05-12-gmt).
> 
> If that has been checked, then yes ``obviously''.

A few don't build; none of them are my fault.  For the record:

	At least fr30-elf, mn10300-elf, and v850-elf have missing
dependencies off in sim/ land; they built with non-parallel make only.

	hppa1.1-hp-proelf wants dl.h and machine/save_state.h in
hppa-tdep.c, and was already marked broken.  The nice gawk segment
doesn't notice that...

	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
	failed with this message (also JB_SP for Sparc):

In file included from /usr/include/setjmp.h:30,
                 from ../../src-build/gdb/top.c:58:
/usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
tm.h:57: warning: this is the location of the previous definition
make[1]: *** [top.o] Error 1

	sh-hms failed with a reference to some new SHmedia code.

	x86-64 failed with:

libgdb.a(solib.o): In function `clear_solib':
/opt/src/gdb/crossbuild/obj.x86_64-linux-gnu/gdb/../../src-build/gdb/solib.c:742:
	undefined reference to `disable_breakpoints_in_shlibs'
libgdb.a(solib-svr4.o): In function `enable_break':
/opt/src/gdb/crossbuild/obj.x86_64-linux-gnu/gdb/../../src-build/gdb/solib-svr4.c:856:
	undefined reference to `remove_solib_event_breakpoints'
/opt/src/gdb/crossbuild/obj.x86_64-linux-gnu/gdb/../../src-build/gdb/solib-svr4.c:983:
	undefined reference to `create_solib_event_breakpoint'

Is x86-64 really "maintenance only"?


Anyway, committed.

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

Re: [RFA] Type cleanups

[Andrew Cagney]

>> Did you check all the cross targets build per MAINTAINERS?  From memory 
>> sh-hms[bfd] and avr[need to look] don't build at present (well as of 
>> ~2002-05-12-gmt).
>> 
>> If that has been checked, then yes ``obviously''.
> 
> 
> A few don't build; none of them are my fault.  For the record:
> 
> 	At least fr30-elf, mn10300-elf, and v850-elf have missing
> dependencies off in sim/ land; they built with non-parallel make only.

> 	hppa1.1-hp-proelf wants dl.h and machine/save_state.h in
> hppa-tdep.c, and was already marked broken.  The nice gawk segment
> doesn't notice that...

HP/UX isn't on the list.  I get:

hppa1.1-hp-proelf broken

The note should probably mention that you normally want to stip out 
broken targets.

> 	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
> 	failed with this message (also JB_SP for Sparc):
> 
> In file included from /usr/include/setjmp.h:30,
>                  from ../../src-build/gdb/top.c:58:
> /usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
> tm.h:57: warning: this is the location of the previous definition
> make[1]: *** [top.o] Error 1

I don't get that on the three systems I use.  Bug in the system library?

> 
> 	sh-hms failed with a reference to some new SHmedia code.

Yes, per above, BFD problem.  sh-hms doesn't enable full SH support in BFD.

Andrew

Re: [RFA] Type cleanups

[Elena Zannoni]

Andrew Cagney writes:
 > 
 > >> Did you check all the cross targets build per MAINTAINERS?  From memory 
 > >> sh-hms[bfd] and avr[need to look] don't build at present (well as of 
 > >> ~2002-05-12-gmt).
 > >> 
 > >> If that has been checked, then yes ``obviously''.
 > > 
 > > 
 > > A few don't build; none of them are my fault.  For the record:
 > > 
 > > 	At least fr30-elf, mn10300-elf, and v850-elf have missing
 > > dependencies off in sim/ land; they built with non-parallel make only.
 > 
 > > 	hppa1.1-hp-proelf wants dl.h and machine/save_state.h in
 > > hppa-tdep.c, and was already marked broken.  The nice gawk segment
 > > doesn't notice that...
 > 
 > HP/UX isn't on the list.  I get:
 > 
 > hppa1.1-hp-proelf broken
 > 
 > The note should probably mention that you normally want to stip out 
 > broken targets.
 > 
 > > 	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
 > > 	failed with this message (also JB_SP for Sparc):
 > > 
 > > In file included from /usr/include/setjmp.h:30,
 > >                  from ../../src-build/gdb/top.c:58:
 > > /usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
 > > tm.h:57: warning: this is the location of the previous definition
 > > make[1]: *** [top.o] Error 1
 > 
 > I don't get that on the three systems I use.  Bug in the system library?
 > 
 > > 
 > > 	sh-hms failed with a reference to some new SHmedia code.
 > 
 > Yes, per above, BFD problem.  sh-hms doesn't enable full SH support in BFD.
 > 

Yes.
I am looking into this right now.
Elena


 > Andrew
 > 
 > 
 > 
 > 
 > 

Re: [RFA] Type cleanups

[Andrew Cagney]

>  > Yes, per above, BFD problem.  sh-hms doesn't enable full SH support in BFD.
>  > 
> 
> Yes.
> I am looking into this right now.
> Elena

BTW, should sh-hms be dropped from the build list?  The files it uses 
merged into the base sh-elf (becomming sh-*)?

Andrew

Re: [RFA] Type cleanups

[Elena Zannoni]

Andrew Cagney writes:
 > >  > Yes, per above, BFD problem.  sh-hms doesn't enable full SH support in BFD.
 > >  > 
 > > 
 > > Yes.
 > > I am looking into this right now.
 > > Elena
 > 
 > BTW, should sh-hms be dropped from the build list?  The files it uses 
 > merged into the base sh-elf (becomming sh-*)?
 > 
 > Andrew
 > 

Don't know. All I know is that it is a coff target. I am looking into
a way to not use the print_insn_sh64 directly from gdb. That's the one
my build is barfing on.

Another question, do we still support sh-pe? Wasn't this the wince target
we deleted a few months back?

Elena

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 12:31:09AM -0400, Andrew Cagney wrote:
> >Does this mean that ``struct type *'' is becoming opaque?  Looking at 
> >>the next patch, no, sigh.
> >
> >
> >No.  It's accessed so frequently that switching from macros to accessor
> >functions would be a ridiculous performance hit, I think.
> 
> The last time this came up, the consensus was that a macro should be 
> converted to a function, even when it resulted in a performance loss 
> (things were a bit vague on how much).  The debate was about STREQ which 
> is in the critical path for symbol table reading and the like.

STREQ is an entirely different problem, IMHO.  For one thing, compilers
do a pretty good job of strcmp on their own; for another, the function
call is heavily optimized.

> Anyway, I tend to look at it more pragmatically.  Is my (your, and other 
> developers) time best spent chasing after people that forget to or 
> wrongly use the accessor macro, or, on fixing real problems.  Given that 
> I'm struggling to show a performance gain from a frame based register 
> cache, and no one has noticed me adding another assertion to every 
> gdbarch accessor function, I don't expect changing the above to opaque 
> to be a significant problem :-)

I think you may be underestimating the frequency of some of the TYPE
accessors... but if I get a chance, I'll benchmark it.

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

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 11:37:29AM -0400, Andrew Cagney wrote:
> 
> >>Did you check all the cross targets build per MAINTAINERS?  From memory 
> >>sh-hms[bfd] and avr[need to look] don't build at present (well as of 
> >>~2002-05-12-gmt).
> >>
> >>If that has been checked, then yes ``obviously''.
> >
> >
> >A few don't build; none of them are my fault.  For the record:
> >
> >	At least fr30-elf, mn10300-elf, and v850-elf have missing
> >dependencies off in sim/ land; they built with non-parallel make only.
> 
> >	hppa1.1-hp-proelf wants dl.h and machine/save_state.h in
> >hppa-tdep.c, and was already marked broken.  The nice gawk segment
> >doesn't notice that...
> 
> HP/UX isn't on the list.  I get:
> 
> hppa1.1-hp-proelf broken
> 
> The note should probably mention that you normally want to stip out 
> broken targets.
> 
> >	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
> >	failed with this message (also JB_SP for Sparc):
> >
> >In file included from /usr/include/setjmp.h:30,
> >                 from ../../src-build/gdb/top.c:58:
> >/usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
> >tm.h:57: warning: this is the location of the previous definition
> >make[1]: *** [top.o] Error 1
> 
> I don't get that on the three systems I use.  Bug in the system library?

Hmm, I'm not sure where the necessary preprocessor definitions are
coming from to make that definition visible.  I'll look in to it.

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

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 02:50:31PM -0400, Daniel Jacobowitz wrote:
> On Mon, May 13, 2002 at 11:37:29AM -0400, Andrew Cagney wrote:
> > 
> > >>Did you check all the cross targets build per MAINTAINERS?  From memory 
> > >>sh-hms[bfd] and avr[need to look] don't build at present (well as of 
> > >>~2002-05-12-gmt).
> > >>
> > >>If that has been checked, then yes ``obviously''.
> > >
> > >
> > >A few don't build; none of them are my fault.  For the record:
> > >
> > >	At least fr30-elf, mn10300-elf, and v850-elf have missing
> > >dependencies off in sim/ land; they built with non-parallel make only.
> > 
> > >	hppa1.1-hp-proelf wants dl.h and machine/save_state.h in
> > >hppa-tdep.c, and was already marked broken.  The nice gawk segment
> > >doesn't notice that...
> > 
> > HP/UX isn't on the list.  I get:
> > 
> > hppa1.1-hp-proelf broken
> > 
> > The note should probably mention that you normally want to stip out 
> > broken targets.
> > 
> > >	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
> > >	failed with this message (also JB_SP for Sparc):
> > >
> > >In file included from /usr/include/setjmp.h:30,
> > >                 from ../../src-build/gdb/top.c:58:
> > >/usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
> > >tm.h:57: warning: this is the location of the previous definition
> > >make[1]: *** [top.o] Error 1
> > 
> > I don't get that on the three systems I use.  Bug in the system library?
> 
> Hmm, I'm not sure where the necessary preprocessor definitions are
> coming from to make that definition visible.  I'll look in to it.

Answer:  apparently it is standards-conforming to define JB_* in
<setjmp.h>.  This means that all of the tm-*.h files which define JB_
variables are somewhat dubious.  We should probably rename our copies
of these constants.  And kill the ones we don't use, which amounts to
almost all of them.

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

Re: [RFA] Type cleanups

[Daniel Berlin]

> > cache, and no one has noticed me adding another assertion to every 
> > gdbarch accessor function, I don't expect changing the above to opaque 
> > to be a significant problem :-)
> 
> I think you may be underestimating the frequency of some of the TYPE
> accessors... but if I get a chance, I'll benchmark it.
If worst comes to worst, you can always make them static inlines in the 
header.
That way, you can still debug them easily, but if optimization is on, ....
--Dan

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 03:54:29PM -0400, Daniel Berlin wrote:
> > > cache, and no one has noticed me adding another assertion to every 
> > > gdbarch accessor function, I don't expect changing the above to opaque 
> > > to be a significant problem :-)
> > 
> > I think you may be underestimating the frequency of some of the TYPE
> > accessors... but if I get a chance, I'll benchmark it.
> If worst comes to worst, you can always make them static inlines in the 
> header.
> That way, you can still debug them easily, but if optimization is on, ....
> --Dan

The problem is, then the type isn't opaque.  Or if it is, it's opaque
via some casting, which makes debugging more annoying.

(Though I should really just write some good gdb macros and utility
functions for debugging types; with the other type patch I posted,
printing the type becomes somewhat less useful.)

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

Re: [RFA] Type cleanups

[Andrew Cagney]

> I don't get that on the three systems I use.  Bug in the system library?
> 
>> 
>> Hmm, I'm not sure where the necessary preprocessor definitions are
>> coming from to make that definition visible.  I'll look in to it.
> 
> 
> Answer:  apparently it is standards-conforming to define JB_* in
> <setjmp.h>.  This means that all of the tm-*.h files which define JB_
> variables are somewhat dubious.  We should probably rename our copies
> of these constants.  And kill the ones we don't use, which amounts to
> almost all of them.

So something like:

/^#[[:space:]]*define[[:space:]]*JB_/

should be ARIed as well?

If yes, I'll do that and add a corresponding bug report.

Andrew

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Mon, May 13, 2002 at 06:15:02PM -0400, Andrew Cagney wrote:
> >I don't get that on the three systems I use.  Bug in the system library?
> >
> >>
> >>Hmm, I'm not sure where the necessary preprocessor definitions are
> >>coming from to make that definition visible.  I'll look in to it.
> >
> >
> >Answer:  apparently it is standards-conforming to define JB_* in
> ><setjmp.h>.  This means that all of the tm-*.h files which define JB_
> >variables are somewhat dubious.  We should probably rename our copies
> >of these constants.  And kill the ones we don't use, which amounts to
> >almost all of them.
> 
> So something like:
> 
> /^#[[:space:]]*define[[:space:]]*JB_/
> 
> should be ARIed as well?
> 
> If yes, I'll do that and add a corresponding bug report.

That sounds like a good idea to me.  These constants obviously appear
in host headers, so we shouldn't be defining them for target headers.
The references will change name naturally when the definitions do.

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

Re: [RFA] Type cleanups

[Elena Zannoni]

Ok, I killed sh-hms, and in case you need it for this patch (I guess
Andrew already green-lighted it, though) you have my approval.

Elena


Daniel Jacobowitz writes:

 > On Mon, May 13, 2002 at 06:15:02PM -0400, Andrew Cagney wrote:
 > > >I don't get that on the three systems I use.  Bug in the system library?
 > > >
 > > >>
 > > >>Hmm, I'm not sure where the necessary preprocessor definitions are
 > > >>coming from to make that definition visible.  I'll look in to it.
 > > >
 > > >
 > > >Answer:  apparently it is standards-conforming to define JB_* in
 > > ><setjmp.h>.  This means that all of the tm-*.h files which define JB_
 > > >variables are somewhat dubious.  We should probably rename our copies
 > > >of these constants.  And kill the ones we don't use, which amounts to
 > > >almost all of them.
 > > 
 > > So something like:
 > > 
 > > /^#[[:space:]]*define[[:space:]]*JB_/
 > > 
 > > should be ARIed as well?
 > > 
 > > If yes, I'll do that and add a corresponding bug report.
 > 
 > That sounds like a good idea to me.  These constants obviously appear
 > in host headers, so we shouldn't be defining them for target headers.
 > The references will change name naturally when the definitions do.
 > 
 > -- 
 > Daniel Jacobowitz                           Carnegie Mellon University
 > MontaVista Software                         Debian GNU/Linux Developer

Re: [RFA] Type cleanups

[Andrew Cagney]

> If yes, I'll do that and add a corresponding bug report.
> 
> 
> That sounds like a good idea to me.  These constants obviously appear
> in host headers, so we shouldn't be defining them for target headers.
> The references will change name naturally when the definitions do.

Done (results won't be up for ~24 hrs though).

Andrew

Re: [RFA] Type cleanups

[Eli Zaretskii]

> Date: Mon, 13 May 2002 09:59:50 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> 	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
> 	failed with this message (also JB_SP for Sparc):
> 
> In file included from /usr/include/setjmp.h:30,
>                  from ../../src-build/gdb/top.c:58:
> /usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
> tm.h:57: warning: this is the location of the previous definition
> make[1]: *** [top.o] Error 1

How come /usr/include/setjmp.h is being used for the DJGPP build?  It
should have used the headers from the cross-compilation toolkit,
i.e. the headers that come with DJGPP development enviroment.  And
those don't define no steenking JB_PC.

What am I missing?  Are we talking about building a native DJGPP port
of GDB, or about something else?

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Fri, May 17, 2002 at 11:09:20AM +0300, Eli Zaretskii wrote:
> > Date: Mon, 13 May 2002 09:59:50 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > 	Several targets (i586-pc-msdosdjgpp, sparc-elf, sparc64-elf)
> > 	failed with this message (also JB_SP for Sparc):
> > 
> > In file included from /usr/include/setjmp.h:30,
> >                  from ../../src-build/gdb/top.c:58:
> > /usr/include/bits/setjmp.h:31: warning: `JB_PC' redefined
> > tm.h:57: warning: this is the location of the previous definition
> > make[1]: *** [top.o] Error 1
> 
> How come /usr/include/setjmp.h is being used for the DJGPP build?  It
> should have used the headers from the cross-compilation toolkit,
> i.e. the headers that come with DJGPP development enviroment.  And
> those don't define no steenking JB_PC.
> 
> What am I missing?  Are we talking about building a native DJGPP port
> of GDB, or about something else?

Cross build, not foreign host build - i.e. an i386-linux -> djgpp cross
debugger.  <setjmp.h> is needed for GDB to use on its own, and does
define these constants.

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

Re: [RFA] Type cleanups

[Eli Zaretskii]

> Date: Fri, 17 May 2002 11:02:44 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> Cross build, not foreign host build - i.e. an i386-linux -> djgpp cross
> debugger.

Sorry, I still don't understand: does this mean a remote debugger with
some stub on the remote DOS/Windows machine?  Or maybe the stub (or
gdbserver) running inside DOSEmu on the GNU/Linux box?

My point is that DJGPP debugging is very special: there's no OS
provision for system calls like ptrace etc., so the only way to debug
a DJGPP inferior is to run it natively under a specially built program
that is linked against the DJGPP debug support library.  I'm curious
how does your cross build achieve that, since I believe neither
gdbserver nor any of the remote-* modules support DJGPP as of now.

Do I understand correctly that the build in question uses
i386/tm-go32.h, and that its definition of JB_PC was the culprit?

Re: [RFA] Type cleanups

[Daniel Jacobowitz]

On Fri, May 17, 2002 at 07:13:07PM +0300, Eli Zaretskii wrote:
> > Date: Fri, 17 May 2002 11:02:44 -0400
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Cross build, not foreign host build - i.e. an i386-linux -> djgpp cross
> > debugger.
> 
> Sorry, I still don't understand: does this mean a remote debugger with
> some stub on the remote DOS/Windows machine?  Or maybe the stub (or
> gdbserver) running inside DOSEmu on the GNU/Linux box?

Those are both valid.

> My point is that DJGPP debugging is very special: there's no OS
> provision for system calls like ptrace etc., so the only way to debug
> a DJGPP inferior is to run it natively under a specially built program
> that is linked against the DJGPP debug support library.  I'm curious
> how does your cross build achieve that, since I believe neither
> gdbserver nor any of the remote-* modules support DJGPP as of now.

I didn't say it would be useful.  But consult MAINTAINERS; everything
listed in the "Targets" section on a --target= line is currently
"expected" to be buildable as a cross debugger, to sanity check
changes.  That's all I was doing.

> Do I understand correctly that the build in question uses
> i386/tm-go32.h, and that its definition of JB_PC was the culprit?

Yes.

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

Re: [RFA] Type cleanups

[Andrew Cagney]

> 
> Those are both valid.
> 
> 
>> My point is that DJGPP debugging is very special: there's no OS
>> provision for system calls like ptrace etc., so the only way to debug
>> a DJGPP inferior is to run it natively under a specially built program
>> that is linked against the DJGPP debug support library.  I'm curious
>> how does your cross build achieve that, since I believe neither
>> gdbserver nor any of the remote-* modules support DJGPP as of now.
> 
> 
> I didn't say it would be useful.  But consult MAINTAINERS; everything
> listed in the "Targets" section on a --target= line is currently
> "expected" to be buildable as a cross debugger, to sanity check
> changes.  That's all I was doing.

Yes.  It exposes header files, not covered by the more generic i386-elf 
target, to the compiler.

Andrew

Re: [RFA] Type cleanups

[Eli Zaretskii]

> Date: Fri, 17 May 2002 13:21:46 -0400
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Sorry, I still don't understand: does this mean a remote debugger with
> > some stub on the remote DOS/Windows machine?  Or maybe the stub (or
> > gdbserver) running inside DOSEmu on the GNU/Linux box?
> 
> Those are both valid.
> 
> > My point is that DJGPP debugging is very special: there's no OS
> > provision for system calls like ptrace etc., so the only way to debug
> > a DJGPP inferior is to run it natively under a specially built program
> > that is linked against the DJGPP debug support library.  I'm curious
> > how does your cross build achieve that, since I believe neither
> > gdbserver nor any of the remote-* modules support DJGPP as of now.
> 
> I didn't say it would be useful.  But consult MAINTAINERS; everything
> listed in the "Targets" section on a --target= line is currently
> "expected" to be buildable as a cross debugger, to sanity check
> changes.  That's all I was doing.

Then I don't think you (or anyone else on this list) should be
concerned with these problems: IMHO, a failure to build a
dysfunctional version of GDB is not a failure at all.

Re: [RFA] Type cleanups

[Eli Zaretskii]

> Date: Fri, 17 May 2002 13:34:53 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> It exposes header files, not covered by the more generic i386-elf 
> target, to the compiler.

tm-go32.h is written for the DJGPP headers.  So that build effectively
mixes two sets of incompatible headers.  Why should we expect anything
but trouble?  Why should we be bothered that the trouble indeed
happens?