2007-06-19 Markus Deuling <deuling@de.ibm.com>
[deliverable/binutils-gdb.git] / gdb / value.c
index 26ba2a44898b7bc54d4166543ac390ee077030b8..52ba2ed90b27d3a6ffa8bf0231ba56bb1afb08a2 100644 (file)
@@ -758,7 +758,7 @@ lookup_internalvar (char *name)
   var = (struct internalvar *) xmalloc (sizeof (struct internalvar));
   var->name = concat (name, (char *)NULL);
   var->value = allocate_value (builtin_type_void);
-  var->endian = TARGET_BYTE_ORDER;
+  var->endian = gdbarch_byte_order (current_gdbarch);
   release_value (var->value);
   var->next = internalvars;
   internalvars = var;
@@ -790,7 +790,7 @@ value_of_internalvar (struct internalvar *var)
      point types) are left alone, because they would be too complicated
      to correct.  */
 
-  if (var->endian != TARGET_BYTE_ORDER)
+  if (var->endian != gdbarch_byte_order (current_gdbarch))
     {
       gdb_byte *array = value_contents_raw (val);
       struct type *type = check_typedef (value_enclosing_type (val));
@@ -847,7 +847,7 @@ set_internalvar (struct internalvar *var, struct value *val)
      long.  */
   xfree (var->value);
   var->value = newval;
-  var->endian = TARGET_BYTE_ORDER;
+  var->endian = gdbarch_byte_order (current_gdbarch);
   release_value (newval);
   /* End code which must not call error().  */
 }
@@ -962,10 +962,10 @@ value_as_address (struct value *val)
   /* Assume a CORE_ADDR can fit in a LONGEST (for now).  Not sure
      whether we want this to be true eventually.  */
 #if 0
-  /* ADDR_BITS_REMOVE is wrong if we are being called for a
+  /* gdbarch_addr_bits_remove is wrong if we are being called for a
      non-address (e.g. argument to "signal", "info break", etc.), or
      for pointers to char, in which the low bits *are* significant.  */
-  return ADDR_BITS_REMOVE (value_as_long (val));
+  return gdbarch_addr_bits_remove (current_gdbarch, value_as_long (val));
 #else
 
   /* There are several targets (IA-64, PowerPC, and others) which
@@ -1138,7 +1138,7 @@ unpack_double (struct type *type, const gdb_byte *valaddr, int *invp)
         only in a non-portable way.  Fixing the portability problem
         wouldn't help since the VAX floating-point code is also badly
         bit-rotten.  The target needs to add definitions for the
-        methods TARGET_FLOAT_FORMAT and TARGET_DOUBLE_FORMAT - these
+        methods gdbarch_float_format and gdbarch_double_format - these
         exactly describe the target floating-point format.  The
         problem here is that the corresponding floatformat_vax_f and
         floatformat_vax_d values these methods should be set to are
@@ -1654,7 +1654,7 @@ coerce_enum (struct value *arg)
 \f
 
 /* Should we use DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS instead of
-   EXTRACT_RETURN_VALUE?  GCC_P is true if compiled with gcc and TYPE
+   gdbarch_extract_return_value?  GCC_P is true if compiled with gcc and TYPE
    is the type (which is known to be struct, union or array).
 
    On most machines, the struct convention is used unless we are
This page took 0.024097 seconds and 4 git commands to generate.