2007-08-17 Michael Snyder <msnyder@access-company.com>

[deliverable/binutils-gdb.git] / gdb / value.c

diff --git a/gdb/value.c b/gdb/value.c
index 6b7aae660c433cd50856c71b21b23f9887f5b622..52ba2ed90b27d3a6ffa8bf0231ba56bb1afb08a2 100644 (file)
--- a/gdb/value.c
+++ b/gdb/value.c
@@ -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