X-Git-Url: http://drtracing.org/?a=blobdiff_plain;f=gdb%2Fdoc%2Fgdbint.texinfo;h=37a6e3c8dc520d5bef95b286d94cc0f64ef97be6;hb=c2c6d25f0d5eea4f834420870021a8c52db24018;hp=a94fcc40389fd19de7cf767874943effc105140c;hpb=30727aa6d12fb866494020c0b62ab265a2bdcdfe;p=deliverable%2Fbinutils-gdb.git diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo index a94fcc4038..37a6e3c8dc 100644 --- a/gdb/doc/gdbint.texinfo +++ b/gdb/doc/gdbint.texinfo @@ -262,10 +262,10 @@ limited in number; when the user asks for more, GDB will start trying to set software breakpoints. Software breakpoints require GDB to do somewhat more work. The basic -theory is that GDB will replace a program instruction a trap, illegal -divide, or some other instruction that will cause an exception, and then -when it's encountered, GDB will take the exception and stop the program. -When the user says to continue, GDB will restore the original +theory is that GDB 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, GDB will take the exception and stop the +program. When the user says to continue, GDB 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 @@ -361,7 +361,7 @@ command), and it can also read more symbols via the ``add-file'' and Symbol files are initially opened by code in @file{symfile.c} using the BFD library. BFD identifies the type of the file by examining its -header. @code{symfile_init} then uses this identification to locate a +header. @code{find_sym_fns} then uses this identification to locate a set of symbol-reading functions. Symbol reading modules identify themselves to GDB by calling @@ -1418,11 +1418,6 @@ partial-stab.h is used to mangle multiple-symbol-table files from HPPA's. This should all be ripped out, and a scheme like elfread.c used. -@item GDB_TARGET_IS_MACH386 -@item GDB_TARGET_IS_SUN3 -@item GDB_TARGET_IS_SUN386 -Kludges that should go away. - @item GET_LONGJMP_TARGET For most machines, this is a target-dependent parameter. On the DECstation and the Iris, this is a native-dependent parameter, since @@ -1486,6 +1481,17 @@ trampoline that connects to a shared library. Define this to evaluate to nonzero if the program is stopped in the trampoline that returns from a shared library. +@item IN_SOLIB_DYNSYM_RESOLVE_CODE pc +Define this to evaluate to nonzero if the program is stopped in the +dynamic linker. + +@item SKIP_SOLIB_RESOLVER pc +Define this to evaluate to the (nonzero) address at which execution +should continue to get past the dynamic linker's symbol resolution +function. A zero value indicates that it is not important or necessary +to set a breakpoint to get through the dynamic linker and that single +stepping will suffice. + @item IS_TRAPPED_INTERNALVAR (name) This is an ugly hook to allow the specification of special actions that should occur as a side-effect of setting the value of a variable @@ -1590,6 +1596,16 @@ defined, no conversion will be done. @item SHIFT_INST_REGS (Only used for m88k targets.) +@item SKIP_PERMANENT_BREAKPOINT +Advance the inferior's PC past a permanent breakpoint. GDB normally +steps over a breakpoint by removing it, stepping one instruction, and +re-inserting the breakpoint. However, permanent breakpoints are +hardwired into the inferior, and can't be removed, so this strategy +doesn't work. Calling SKIP_PERMANENT_BREAKPOINT adjusts the processor's +state so that execution will resume just after the breakpoint. This +macro does the right thing even when the breakpoint is in the delay slot +of a branch or jump. + @item SKIP_PROLOGUE (pc) A C expression that returns the address of the ``real'' code beyond the function entry prologue found at @var{pc}. @@ -1749,10 +1765,13 @@ The following files define a target to GDB: @item gdb/config/@var{arch}/@var{ttt}.mt Contains a Makefile fragment specific to this target. Specifies what object files are needed for target @var{ttt}, by defining -@samp{TDEPFILES=@dots{}}. Also specifies the header file which -describes @var{ttt}, by defining @samp{TM_FILE= tm-@var{ttt}.h}. You -can also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, @samp{TM_CDEPS}, but -these are now deprecated and may go away in future versions of GDB. +@samp{TDEPFILES=@dots{}} and @samp{TDEPLIBS=@dots{}}. Also specifies +the header file which describes @var{ttt}, by defining @samp{TM_FILE= +tm-@var{ttt}.h}. + +You can also define @samp{TM_CFLAGS}, @samp{TM_CLIBS}, @samp{TM_CDEPS}, +but these are now deprecated, replaced by autoconf, and may go away in +future versions of GDB. @item gdb/config/@var{arch}/tm-@var{ttt}.h (@file{tm.h} is a link to this file, created by configure). Contains @@ -2365,35 +2384,15 @@ are just as hard to understand as a single thousand-line function. @subsection Function Prototypes -Prototypes must be used to @emph{declare} functions but never to +Prototypes must be used to @emph{declare} functions, and may be used to @emph{define} them. Prototypes for GDB functions must include both the argument type and name, with the name matching that used in the actual function definition. -For the sake of compatibility with pre-ANSI compilers, define prototypes -with the @code{PARAMS} macro: - -@example @code -extern int memory_remove_breakpoint PARAMS ((CORE_ADDR addr, - char *contents_cache)); -@end example - -Note the double parentheses around the parameter types. This allows an -arbitrary number of parameters to be described, without freaking out the -C preprocessor. When the function has no parameters, it should be -described like: - -@example @code -extern void noprocess PARAMS ((void)); -@end example - -The @code{PARAMS} macro expands to its argument in ANSI C, or to a -simple @code{()} in traditional C. - -All external functions should have a @code{PARAMS} declaration in a -header file that callers include, except for @code{_initialize_*} -functions, which must be external so that @file{init.c} construction -works, but shouldn't be visible to random source files. +All external functions should have a declaration in a header file that +callers include, except for @code{_initialize_*} functions, which must +be external so that @file{init.c} construction works, but shouldn't be +visible to random source files. All static functions must be declared in a block near the top of the source file. @@ -2770,7 +2769,7 @@ also documents all the available macros. @c Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete @c Conditionals}) -Start with the header files. Once you some idea of how GDB's internal +Start with the header files. Once you have some idea of how GDB's internal symbol tables are stored (see @file{symtab.h}, @file{gdbtypes.h}), you will find it much easier to understand the code which uses and creates those symbol tables.