summaryrefslogtreecommitdiff
path: root/gdb/defs.h
diff options
context:
space:
mode:
authorAndrew Cagney <cagney@redhat.com>2001-06-15 22:10:21 +0000
committerAndrew Cagney <cagney@redhat.com>2001-06-15 22:10:21 +0000
commit04201ba910bb5a27ecaa5202fb05c89a37c427e9 (patch)
treed89e178ebda01318a6e1d72ae2de277d57ae5fe2 /gdb/defs.h
parent17e0a8c1757379145028cb80f9178c600a9c3aa7 (diff)
downloadgdb-04201ba910bb5a27ecaa5202fb05c89a37c427e9.tar.gz
multi-arch ADDR_BITS_REMOVE.
Diffstat (limited to 'gdb/defs.h')
-rw-r--r--gdb/defs.h13
1 files changed, 0 insertions, 13 deletions
diff --git a/gdb/defs.h b/gdb/defs.h
index 56d8d7b4c80..03113d56614 100644
--- a/gdb/defs.h
+++ b/gdb/defs.h
@@ -1259,19 +1259,6 @@ extern char *floatformat_mantissa (const struct floatformat *, char *);
extern DOUBLEST extract_floating (void *, int);
extern void store_floating (void *, int, DOUBLEST);
-/* On some machines there are bits in addresses which are not really
- part of the address, but are used by the kernel, the hardware, etc.
- for special purposes. ADDR_BITS_REMOVE takes out any such bits
- so we get a "real" address such as one would find in a symbol
- table. This is used only for addresses of instructions, and even then
- I'm not sure it's used in all contexts. It exists to deal with there
- being a few stray bits in the PC which would mislead us, not as some sort
- of generic thing to handle alignment or segmentation (it's possible it
- should be in TARGET_READ_PC instead). */
-#if !defined (ADDR_BITS_REMOVE)
-#define ADDR_BITS_REMOVE(addr) (addr)
-#endif /* No ADDR_BITS_REMOVE. */
-
/* From valops.c */
extern CORE_ADDR push_bytes (CORE_ADDR, char *, int);