gdbint.texinfo

这个是LINUX下的GDB调度工具的源码

\input texinfo   @c -*- texinfo -*-
@setfilename gdbint.info
@include gdb-cfg.texi
@dircategory Software development
@direntry
* Gdb-Internals: (gdbint).	The GNU debugger's internals.
@end direntry

@ifinfo
This file documents the internals of the GNU debugger @value{GDBN}.
Copyright 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001,2002,2003,2004
   Free Software Foundation, Inc.
Contributed by Cygnus Solutions.  Written by John Gilmore.
Second Edition by Stan Shebs.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts.  A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
@end ifinfo

@setchapternewpage off
@settitle @value{GDBN} Internals

@syncodeindex fn cp
@syncodeindex vr cp

@titlepage
@title @value{GDBN} Internals
@subtitle{A guide to the internals of the GNU debugger}
@author John Gilmore
@author Cygnus Solutions
@author Second Edition:
@author Stan Shebs
@author Cygnus Solutions
@page
@tex
\def\$#1${{#1}}  % Kluge: collect RCS revision info without $...$
\xdef\manvers{\$Revision$}  % For use in headers, footers too
{\parskip=0pt
\hfill Cygnus Solutions\par
\hfill \manvers\par
\hfill \TeX{}info \texinfoversion\par
}
@end tex

@vskip 0pt plus 1filll
Copyright @copyright{} 1990,1991,1992,1993,1994,1996,1998,1999,2000,2001,
   2002, 2003, 2004  Free Software Foundation, Inc.

Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with no
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
Texts.  A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
@end titlepage

@contents

@node Top
@c Perhaps this should be the title of the document (but only for info,
@c not for TeX).  Existing GNU manuals seem inconsistent on this point.
@top Scope of this Document

This document documents the internals of the GNU debugger, @value{GDBN}.  It
includes description of @value{GDBN}'s key algorithms and operations, as well
as the mechanisms that adapt @value{GDBN} to specific hosts and targets.

@menu
* Requirements::
* Overall Structure::
* Algorithms::
* User Interface::
* libgdb::
* Symbol Handling::
* Language Support::
* Host Definition::
* Target Architecture Definition::
* Target Vector Definition::
* Native Debugging::
* Support Libraries::
* Coding::
* Porting GDB::
* Versions and Branches::
* Releasing GDB::
* Testsuite::
* Hints::

* GDB Observers::  @value{GDBN} Currently available observers
* GNU Free Documentation License::  The license for this documentation
* Index::
@end menu

@node Requirements

@chapter Requirements
@cindex requirements for @value{GDBN}

Before diving into the internals, you should understand the formal
requirements and other expectations for @value{GDBN}.  Although some
of these may seem obvious, there have been proposals for @value{GDBN}
that have run counter to these requirements.

First of all, @value{GDBN} is a debugger.  It's not designed to be a
front panel for embedded systems.  It's not a text editor.  It's not a
shell.  It's not a programming environment.

@value{GDBN} is an interactive tool.  Although a batch mode is
available, @value{GDBN}'s primary role is to interact with a human
programmer.

@value{GDBN} should be responsive to the user.  A programmer hot on
the trail of a nasty bug, and operating under a looming deadline, is
going to be very impatient of everything, including the response time
to debugger commands.

@value{GDBN} should be relatively permissive, such as for expressions.
While the compiler should be picky (or have the option to be made
picky), since source code lives for a long time usually, the
programmer doing debugging shouldn't be spending time figuring out to
mollify the debugger.

@value{GDBN} will be called upon to deal with really large programs.
Executable sizes of 50 to 100 megabytes occur regularly, and we've
heard reports of programs approaching 1 gigabyte in size.

@value{GDBN} should be able to run everywhere.  No other debugger is
available for even half as many configurations as @value{GDBN}
supports.


@node Overall Structure

@chapter Overall Structure

@value{GDBN} consists of three major subsystems: user interface,
symbol handling (the @dfn{symbol side}), and target system handling (the
@dfn{target side}).

The user interface consists of several actual interfaces, plus
supporting code.

The symbol side consists of object file readers, debugging info
interpreters, symbol table management, source language expression
parsing, type and value printing.

The target side consists of execution control, stack frame analysis, and
physical target manipulation.

The target side/symbol side division is not formal, and there are a
number of exceptions.  For instance, core file support involves symbolic
elements (the basic core file reader is in BFD) and target elements (it
supplies the contents of memory and the values of registers).  Instead,
this division is useful for understanding how the minor subsystems
should fit together.

@section The Symbol Side

The symbolic side of @value{GDBN} can be thought of as ``everything
you can do in @value{GDBN} without having a live program running''.
For instance, you can look at the types of variables, and evaluate
many kinds of expressions.

@section The Target Side

The target side of @value{GDBN} is the ``bits and bytes manipulator''.
Although it may make reference to symbolic info here and there, most
of the target side will run with only a stripped executable
available---or even no executable at all, in remote debugging cases.

Operations such as disassembly, stack frame crawls, and register
display, are able to work with no symbolic info at all.  In some cases,
such as disassembly, @value{GDBN} will use symbolic info to present addresses
relative to symbols rather than as raw numbers, but it will work either
way.

@section Configurations

@cindex host
@cindex target
@dfn{Host} refers to attributes of the system where @value{GDBN} runs.
@dfn{Target} refers to the system where the program being debugged
executes.  In most cases they are the same machine, in which case a
third type of @dfn{Native} attributes come into play.

Defines and include files needed to build on the host are host support.
Examples are tty support, system defined types, host byte order, host
float format.

Defines and information needed to handle the target format are target
dependent.  Examples are the stack frame format, instruction set,
breakpoint instruction, registers, and how to set up and tear down the stack
to call a function.

Information that is only needed when the host and target are the same,
is native dependent.  One example is Unix child process support; if the
host and target are not the same, doing a fork to start the target
process is a bad idea.  The various macros needed for finding the
registers in the @code{upage}, running @code{ptrace}, and such are all
in the native-dependent files.

Another example of native-dependent code is support for features that
are really part of the target environment, but which require
@code{#include} files that are only available on the host system.  Core
file handling and @code{setjmp} handling are two common cases.

When you want to make @value{GDBN} work ``native'' on a particular machine, you
have to include all three kinds of information.


@node Algorithms

@chapter Algorithms
@cindex algorithms

@value{GDBN} uses a number of debugging-specific algorithms.  They are
often not very complicated, but get lost in the thicket of special
cases and real-world issues.  This chapter describes the basic
algorithms and mentions some of the specific target definitions that
they use.

@section Frames

@cindex frame
@cindex call stack frame
A frame is a construct that @value{GDBN} uses to keep track of calling
and called functions.

@findex create_new_frame
@vindex FRAME_FP
@code{FRAME_FP} in the machine description has no meaning to the
machine-independent part of @value{GDBN}, except that it is used when
setting up a new frame from scratch, as follows:

@smallexample
create_new_frame (read_register (DEPRECATED_FP_REGNUM), read_pc ()));
@end smallexample

@cindex frame pointer register
Other than that, all the meaning imparted to @code{DEPRECATED_FP_REGNUM}
is imparted by the machine-dependent code.  So,
@code{DEPRECATED_FP_REGNUM} can have any value that is convenient for
the code that creates new frames.  (@code{create_new_frame} calls
@code{DEPRECATED_INIT_EXTRA_FRAME_INFO} if it is defined; that is where
you should use the @code{DEPRECATED_FP_REGNUM} value, if your frames are
nonstandard.)

@cindex frame chain
Given a @value{GDBN} frame, define @code{DEPRECATED_FRAME_CHAIN} to
determine the address of the calling function's frame.  This will be
used to create a new @value{GDBN} frame struct, and then
@code{DEPRECATED_INIT_EXTRA_FRAME_INFO} and
@code{DEPRECATED_INIT_FRAME_PC} will be called for the new frame.

@section Breakpoint Handling

@cindex breakpoints
In general, a breakpoint is a user-designated location in the program
where the user wants to regain control if program execution ever reaches
that location.

There are two main ways to implement breakpoints; either as ``hardware''
breakpoints or as ``software'' breakpoints.

@cindex hardware breakpoints
@cindex program counter
Hardware breakpoints are sometimes available as a builtin debugging
features with some chips.  Typically these work by having dedicated
register into which the breakpoint address may be stored.  If the PC
(shorthand for @dfn{program counter})
ever matches a value in a breakpoint registers, the CPU raises an
exception and reports it to @value{GDBN}.

Another possibility is when an emulator is in use; many emulators
include circuitry that watches the address lines coming out from the
processor, and force it to stop if the address matches a breakpoint's
address.

A third possibility is that the target already has the ability to do
breakpoints somehow; for instance, a ROM monitor may do its own
software breakpoints.  So although these are not literally ``hardware
breakpoints'', from @value{GDBN}'s point of view they work the same;
@value{GDBN} need not do anything more than set the breakpoint and wait
for something to happen.

Since they depend on hardware resources, hardware breakpoints may be
limited in number; when the user asks for more, @value{GDBN} will
start trying to set software breakpoints.  (On some architectures,
notably the 32-bit x86 platforms, @value{GDBN} cannot always know
whether there's enough hardware resources to insert all the hardware
breakpoints and watchpoints.  On those platforms, @value{GDBN} prints
an error message only when the program being debugged is continued.)

@cindex software breakpoints
Software breakpoints require @value{GDBN} to do somewhat more work.
The basic theory is that @value{GDBN} will replace a program
instruction with a trap, illegal divide, or some other instruction
that will cause an exception, and then when it's encountered,
@value{GDBN} will take the exception and stop the program.  When the
user says to continue, @value{GDBN} will restore the original
instruction, single-step, re-insert the trap, and continue on.

Since it literally overwrites the program being tested, the program area
must be writable, so this technique won't work on programs in ROM.  It
can also distort the behavior of programs that examine themselves,
although such a situation would be highly unusual.

Also, the software breakpoint instruction should be the smallest size of
instruction, so it doesn't overwrite an instruction that might be a jump
target, and cause disaster when the program jumps into the middle of the
breakpoint instruction.  (Strictly speaking, the breakpoint must be no
larger than the smallest interval between instructions that may be jump
targets; perhaps there is an architecture where only even-numbered
instructions may jumped to.)  Note that it's possible for an instruction
set not to have any instructions usable for a software breakpoint,
although in practice only the ARC has failed to define such an
instruction.

@findex BREAKPOINT
The basic definition of the software breakpoint is the macro
@code{BREAKPOINT}.

Basic breakpoint object handling is in @file{breakpoint.c}.  However,
much of the interesting breakpoint action is in @file{infrun.c}.

@section Single Stepping

@section Signal Handling

@section Thread Handling

@section Inferior Function Calls

@section Longjmp Support