* 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:
Stan Shebs 2013-09-16 18:00:34 +00:00
parent a280dbd160
commit 0a7cfe2cf5
11 changed files with 39 additions and 8363 deletions

View file

@ -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