* README: Update references to writing code for GDB.
* configure.ac (build_warnings): Remove obsolete comment. * configure: Regenerate. * gdbarch.sh: Remove references to gdbint.texinfo. * gdbarch.h: Regenerate. * gdbtypes.c (objfile_type): Remove comments referencing internals manual and D10V. [gdb/doc] Remove the internals manual gdbint.texinfo. * Makefile.in (INFO_DEPS): Remove gdbint.info. (PDFFILES): Remove gdbint.pdf. (HTMLFILES): Remove gdbint/index.html. (HTMLFILES_INSTALL): Remove gdbint. (GDBINT_DOC_FILES): Remove. (dvi): Remove gdbint.dvi. (ps): Remove gdbint.ps. * gdbint.texinfo: Remove file. * gdb.texinfo (Maintenance Commands): Remove reference to gdbint.
This commit is contained in:
parent
a280dbd160
commit
0a7cfe2cf5
11 changed files with 39 additions and 8363 deletions
|
@ -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
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue