summaryrefslogtreecommitdiff
path: root/gdb/gdbtypes.c
diff options
context:
space:
mode:
Diffstat (limited to 'gdb/gdbtypes.c')
-rw-r--r--gdb/gdbtypes.c10
1 files changed, 1 insertions, 9 deletions
diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c
index dd2ef96a16d..d4375ae3ddc 100644
--- a/gdb/gdbtypes.c
+++ b/gdb/gdbtypes.c
@@ -4069,9 +4069,7 @@ objfile_type (struct objfile *objfile)
"<thread local variable, no debug info>", objfile);
/* NOTE: on some targets, addresses and pointers are not necessarily
- the same --- for example, on the D10V, pointers are 16 bits long,
- but addresses are 32 bits long. See doc/gdbint.texinfo,
- ``Pointers Are Not Always Addresses''.
+ the same.
The upshot is:
- gdb's `struct type' always describes the target's
@@ -4084,12 +4082,6 @@ objfile_type (struct objfile *objfile)
can access any memory on the target, even if the processor has
separate code and data address spaces.
- So, for example:
- - If v is a value holding a D10V code pointer, its contents are
- in target form: a big-endian address left-shifted two bits.
- - If p is a D10V pointer type, TYPE_LENGTH (p) == 2, just as
- sizeof (void *) == 2 on the target.
-
In this context, objfile_type->builtin_core_addr is a bit odd:
it's a target type for a value the target will never see. It's
only used to hold the values of (typeless) linker symbols, which