[5/10] Add "explicit size" types to builtin_type

[5/10] Add "explicit size" types to builtin_type

[Ulrich Weigand]

Hello,

the builtin_type structure does not contain the builtin types that
are supposedly independent of the gdbarch.  However, as already
noted in comments in gdbtypes.c, this isn't really true: those types
contain pointer_type and reference_type fields caching pointer and
reference types to those base types -- and those will always be
platform-dependent.  Thus the base types must be treated as
platform-dependent as well.

This patch adds all those missing types to the builtin_type structure.

Bye,
Ulrich


ChangeLog:

	* gdbarch.h (struct builtin_type): New members builtin_int0,
	builtin_int8, builtin_uint8, builtin_int16, builtin_uint16,
	builtin_int32, builtin_uint32, builtin_int64, builtin_uint64,
	builtin_int128, builtin_uint128, builtin_ieee_single,
	builtin_ieee_double, builtin_i387_ext, builtin_m68881_ext,
	builtin_arm_ext, builtin_ia64_spill, builtin_ia64_quad.
	* gdbarch.c (gdbtypes_post_init): Initialize them.


diff -urNp gdb-orig/gdb/gdbtypes.c gdb-head/gdb/gdbtypes.c
--- gdb-orig/gdb/gdbtypes.c	2007-06-08 18:25:35.311859405 +0200
+++ gdb-head/gdb/gdbtypes.c	2007-06-08 18:25:42.417900011 +0200
@@ -3583,6 +3583,74 @@ gdbtypes_post_init (struct gdbarch *gdba
 	       TYPE_FLAG_UNSIGNED,
 	       "__bfd_vma", (struct objfile *) NULL);
 
+
+  /* Explicit types. 
+
+     Even though all types below here do not themselves depend on the
+     architecture, we still provide per-architecture instances.  This is
+     because their pointer_type and reference_type fields may refer to
+     types that *are* architecture specific.  */
+
+  builtin_type->builtin_int0 =
+    init_type (TYPE_CODE_INT, 0 / 8,
+	       0,
+	       "int0_t", (struct objfile *) NULL);
+  builtin_type->builtin_int8 =
+    init_type (TYPE_CODE_INT, 8 / 8,
+	       0,
+	       "int8_t", (struct objfile *) NULL);
+  builtin_type->builtin_uint8 =
+    init_type (TYPE_CODE_INT, 8 / 8,
+	       TYPE_FLAG_UNSIGNED,
+	       "uint8_t", (struct objfile *) NULL);
+  builtin_type->builtin_int16 =
+    init_type (TYPE_CODE_INT, 16 / 8,
+	       0,
+	       "int16_t", (struct objfile *) NULL);
+  builtin_type->builtin_uint16 =
+    init_type (TYPE_CODE_INT, 16 / 8,
+	       TYPE_FLAG_UNSIGNED,
+	       "uint16_t", (struct objfile *) NULL);
+  builtin_type->builtin_int32 =
+    init_type (TYPE_CODE_INT, 32 / 8,
+	       0,
+	       "int32_t", (struct objfile *) NULL);
+  builtin_type->builtin_uint32 =
+    init_type (TYPE_CODE_INT, 32 / 8,
+	       TYPE_FLAG_UNSIGNED,
+	       "uint32_t", (struct objfile *) NULL);
+  builtin_type->builtin_int64 =
+    init_type (TYPE_CODE_INT, 64 / 8,
+	       0,
+	       "int64_t", (struct objfile *) NULL);
+  builtin_type->builtin_uint64 =
+    init_type (TYPE_CODE_INT, 64 / 8,
+	       TYPE_FLAG_UNSIGNED,
+	       "uint64_t", (struct objfile *) NULL);
+  builtin_type->builtin_int128 =
+    init_type (TYPE_CODE_INT, 128 / 8,
+	       0,
+	       "int128_t", (struct objfile *) NULL);
+  builtin_type->builtin_uint128 =
+    init_type (TYPE_CODE_INT, 128 / 8,
+	       TYPE_FLAG_UNSIGNED,
+	       "uint128_t", (struct objfile *) NULL);
+
+  builtin_type->builtin_ieee_single
+    = build_flt (-1, "builtin_type_ieee_single", floatformats_ieee_single);
+  builtin_type->builtin_ieee_double
+    = build_flt (-1, "builtin_type_ieee_double", floatformats_ieee_double);
+  builtin_type->builtin_i387_ext
+    = build_flt (-1, "builtin_type_i387_ext", floatformats_i387_ext);
+  builtin_type->builtin_m68881_ext
+    = build_flt (-1, "builtin_type_m68881_ext", floatformats_m68881_ext);
+  builtin_type->builtin_arm_ext
+    = build_flt (-1, "builtin_type_arm_ext", floatformats_arm_ext);
+  builtin_type->builtin_ia64_spill
+    = build_flt (-1, "builtin_type_ia64_spill", floatformats_ia64_spill);
+  builtin_type->builtin_ia64_quad
+    = build_flt (-1, "builtin_type_ia64_quad", floatformats_ia64_quad);
+
   return builtin_type;
 }
 
diff -urNp gdb-orig/gdb/gdbtypes.h gdb-head/gdb/gdbtypes.h
--- gdb-orig/gdb/gdbtypes.h	2007-06-08 18:25:35.356852928 +0200
+++ gdb-head/gdb/gdbtypes.h	2007-06-08 18:25:42.460893821 +0200
@@ -1034,6 +1034,38 @@ struct builtin_type
   struct type *builtin_bool;
   struct type *builtin_long_long;
   struct type *builtin_unsigned_long_long;
+
+
+  /* Explicit types.
+
+     Even though all types below here do not themselves depend on the
+     architecture, we still provide per-architecture instances.  This is
+     because their pointer_type and reference_type fields may refer to
+     types that *are* architecture specific.  */
+
+  /* Explicit integer types - see C9X <intypes.h> for naming scheme.
+     The "int0" is for when an architecture needs to describe a register
+     that has no size.  */
+  struct type *builtin_int0;
+  struct type *builtin_int8;
+  struct type *builtin_uint8;
+  struct type *builtin_int16;
+  struct type *builtin_uint16;
+  struct type *builtin_int32;
+  struct type *builtin_uint32;
+  struct type *builtin_int64;
+  struct type *builtin_uint64;
+  struct type *builtin_int128;
+  struct type *builtin_uint128;
+
+  /* Explicit floating-point types.  */
+  struct type *builtin_ieee_single;
+  struct type *builtin_ieee_double;
+  struct type *builtin_i387_ext;
+  struct type *builtin_m68881_ext;
+  struct type *builtin_arm_ext;
+  struct type *builtin_ia64_spill;
+  struct type *builtin_ia64_quad;
 };
 
 /* Return the type table for the specified architecture.  */
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [5/10] Add "explicit size" types to builtin_type

[Daniel Jacobowitz]

On Sat, Jun 09, 2007 at 01:16:12AM +0200, Ulrich Weigand wrote:
> Hello,
> 
> the builtin_type structure does not contain the builtin types that
> are supposedly independent of the gdbarch.  However, as already
> noted in comments in gdbtypes.c, this isn't really true: those types
> contain pointer_type and reference_type fields caching pointer and
> reference types to those base types -- and those will always be
> platform-dependent.  Thus the base types must be treated as
> platform-dependent as well.
> 
> This patch adds all those missing types to the builtin_type structure.

This one may be a problem.  From tdesc_named_type:

  /* Next try some predefined types.  Note that none of these types
     depend on the current architecture; some of the builtin_type_foo
     variables are swapped based on the architecture.  */
  if (strcmp (id, "int8") == 0)
    return builtin_type_int8;

This function is returning types for register values, before we have
constructed the corresponding gdbarch.  We'll now grab them from some
other random gdbarch (of course, we were sort of doing that before,
but it worked - in practice these types are never used anywhere that
their address can be taken).

I wonder if we could fix this by moving the pointer and reference type
caches out of the types themselves, and into per-architecture data?
Or perhaps use tables based only on the pointer size and other
attributes; they do not really need to be per-architecture, just
cached.  An i386 and i686 can use the same void *.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [5/10] Add "explicit size" types to builtin_type

[Ulrich Weigand]

Daniel Jacobowitz wrote:

> This one may be a problem.  From tdesc_named_type:
> 
>   /* Next try some predefined types.  Note that none of these types
>      depend on the current architecture; some of the builtin_type_foo
>      variables are swapped based on the architecture.  */
>   if (strcmp (id, "int8") == 0)
>     return builtin_type_int8;
> 
> This function is returning types for register values, before we have
> constructed the corresponding gdbarch.  We'll now grab them from some
> other random gdbarch (of course, we were sort of doing that before,
> but it worked - in practice these types are never used anywhere that
> their address can be taken).
> 
> I wonder if we could fix this by moving the pointer and reference type
> caches out of the types themselves, and into per-architecture data?
> Or perhaps use tables based only on the pointer size and other
> attributes; they do not really need to be per-architecture, just
> cached.  An i386 and i686 can use the same void *.

Hmmm.  One thing I liked about the approach in my patch was that
it in effect made *all* types gdbarch-specific.  This would have
allowed in the end to implement something like a get_type_arch ()
routine, which could be quite useful to push references to
current_gdbarch out of the symbol parts of the debugger (where
we often do not have a local gdbarch / frame / regcache argument,
but where we typically operate on types or values).

If we have genuinely architecture-independent types, a routine
like lookup_pointer_type cannot be implemented without reference
to a global current_gdbarch (unless it receives an explicit
gdbarch argument and all callers are modified) ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [5/10] Add "explicit size" types to builtin_type

[Daniel Jacobowitz]

On Tue, Jun 12, 2007 at 06:24:39PM +0200, Ulrich Weigand wrote:
> Hmmm.  One thing I liked about the approach in my patch was that
> it in effect made *all* types gdbarch-specific.  This would have
> allowed in the end to implement something like a get_type_arch ()
> routine, which could be quite useful to push references to
> current_gdbarch out of the symbol parts of the debugger (where
> we often do not have a local gdbarch / frame / regcache argument,
> but where we typically operate on types or values).

That seems to me like a bad idea.  We do not know the gdbarch when we
read in the symbol file.  All references to the current architecture
in the symbol readers are bogus - basically, they only work as long as
the things referenced are the same between any other architectures we
select.  Like pointer size, for instance.  Fortunately the file
usually contains sufficient information for that purpose.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [5/10] Add "explicit size" types to builtin_type

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Tue, Jun 12, 2007 at 06:24:39PM +0200, Ulrich Weigand wrote:
> > Hmmm.  One thing I liked about the approach in my patch was that
> > it in effect made *all* types gdbarch-specific.  This would have
> > allowed in the end to implement something like a get_type_arch ()
> > routine, which could be quite useful to push references to
> > current_gdbarch out of the symbol parts of the debugger (where
> > we often do not have a local gdbarch / frame / regcache argument,
> > but where we typically operate on types or values).
> 
> That seems to me like a bad idea.  We do not know the gdbarch when we
> read in the symbol file.  All references to the current architecture
> in the symbol readers are bogus - basically, they only work as long as
> the things referenced are the same between any other architectures we
> select.  Like pointer size, for instance.  Fortunately the file
> usually contains sufficient information for that purpose.

So are you suggesting that all references to gdbarch in the symbol
readers ought to be removed?  I'm not sure this is feasible, there
are in fact a number of gdbarch callbacks that specifically provide
information only to the symbol parts of GDB (like dwarf2_reg_to_regnum,
or something like skip_prologue).

What I had been thinking of is to explicitly assign a gdbarch to
each objfile (probably as an objfile->arch member).  Now this arch
is -as you mention- not necessarily the same as the "current"
architecture (what will become the per-thread / per-frame
architecture), but it will simply be the gdbarch selected by the
sniffers on the basis of the objfile (bfd) alone.  This arch would
then be used to provide per-platform configuration information to
the symbol parts of GDB.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [5/10] Add "explicit size" types to builtin_type

[Daniel Jacobowitz]

On Wed, Jun 13, 2007 at 04:10:07PM +0200, Ulrich Weigand wrote:
> What I had been thinking of is to explicitly assign a gdbarch to
> each objfile (probably as an objfile->arch member).  Now this arch
> is -as you mention- not necessarily the same as the "current"
> architecture (what will become the per-thread / per-frame
> architecture), but it will simply be the gdbarch selected by the
> sniffers on the basis of the objfile (bfd) alone.  This arch would
> then be used to provide per-platform configuration information to
> the symbol parts of GDB.

I like this idea.  The other thing I was thinking of was a gdbarch
check that two gdbarches have the same methods and constants for the
parts that symbol readers are allowed to use, but that isn't feasible.

-- 
Daniel Jacobowitz
CodeSourcery