@ifinfo
This file documents the internals of the GNU debugger GDB.
-Copyright 1990, 91, 92, 93, 94, 95, 96, 97, 1998 Free Software Foundation, Inc.
+Copyright 1990-1999 Free Software Foundation, Inc.
Contributed by Cygnus Solutions. Written by John Gilmore.
Second Edition by Stan Shebs.
@end tex
@vskip 0pt plus 1filll
-Copyright @copyright{} 1990, 91, 92, 93, 94, 95, 96, 97, 1998 Free Software Foundation, Inc.
+Copyright @copyright{} 1990-1999 Free Software Foundation, Inc.
Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
* Support Libraries::
* Coding::
* Porting GDB::
+* Testsuite::
* Hints::
@end menu
@code{memcpy} and @code{memset}. Define this to avoid conflicts between
the native include files and the declarations in @file{defs.h}.
+@item NO_STD_REGS
+This macro is deprecated.
+
@item NO_SYS_FILE
Define this if your system does not have a @code{<sys/file.h>}.
bfd_seek). FIXME, should be replaced by SEEK_SET instead, which is the
POSIX equivalent.
-@item MAINTENANCE_CMDS
-If the value of this is 1, then a number of optional maintenance
-commands are compiled in.
-
@item MALLOC_INCOMPATIBLE
Define this if the system's prototype for @code{malloc} differs from the
@sc{ANSI} definition.
set correctly if compiling with GCC. This will almost never need to be
defined.
+@item USE_GENERIC_DUMMY_FRAMES
+Define this to 1 if the target is using the generic inferior function
+call code. See @code{blockframe.c} for more information.
+
@item USE_MMALLOC
GDB will use the @code{mmalloc} library for memory allocation for symbol
reading if this symbol is defined. Be careful defining it since there
pattern could be an invalid instruction. The breakpoint must be no
longer than the shortest instruction of the architecture.
+@var{BREAKPOINT} has been deprecated in favour of
+@var{BREAKPOINT_FROM_PC}.
+
@item BIG_BREAKPOINT
@item LITTLE_BREAKPOINT
Similar to BREAKPOINT, but used for bi-endian targets.
+@var{BIG_BREAKPOINT} and @var{LITTLE_BREAKPOINT} have been deprecated in
+favour of @var{BREAKPOINT_FROM_PC}.
+
@item REMOTE_BREAKPOINT
@item LITTLE_REMOTE_BREAKPOINT
@item BIG_REMOTE_BREAKPOINT
Similar to BREAKPOINT, but used for remote targets.
+@var{BIG_REMOTE_BREAKPOINT} and @var{LITTLE_REMOTE_BREAKPOINT} have been
+deprecated in favour of @var{BREAKPOINT_FROM_PC}.
+
@item BREAKPOINT_FROM_PC (pcptr, lenptr)
Use the program counter to determine the contents and size of a
instruction. The breakpoint must be no longer than the shortest
instruction of the architecture.
-Replaces all the other BREAKPOINTs.
+Replaces all the other @var{BREAKPOINT} macros.
+
+@item CALL_DUMMY_P
+A C expresson that is non-zero when the target suports inferior function
+calls.
+
+@item CALL_DUMMY_WORDS
+Pointer to an array of @var{LONGEST} words of data containing
+host-byte-ordered @var{REGISTER_BYTES} sized values that partially
+specify the sequence of instructions needed for an inferior function
+call.
+
+Should be deprecated in favour of a macro that uses target-byte-ordered
+data.
+
+@item SIZEOF_CALL_DUMMY_WORDS
+The size of @var{CALL_DUMMY_WORDS}. When @var{CALL_DUMMY_P} this must
+return a positive value. See also @var{CALL_DUMMY_LENGTH}.
@item CALL_DUMMY
-valops.c
+A static initializer for @var{CALL_DUMMY_WORDS}. Deprecated.
+
@item CALL_DUMMY_LOCATION
inferior.h
+
@item CALL_DUMMY_STACK_ADJUST
-valops.c
+Stack adjustment needed when performing an inferior function call.
+
+Should be deprecated in favor of something like @var{STACK_ALIGN}.
+
+@item CALL_DUMMY_STACK_ADJUST_P
+Predicate for use of @var{CALL_DUMMY_STACK_ADJUST}.
+
+Should be deprecated in favor of something like @var{STACK_ALIGN}.
@item CANNOT_FETCH_REGISTER (regno)
A C expression that should be nonzero if @var{regno} cannot be fetched
into @var{valbuf}.
@item EXTRACT_STRUCT_VALUE_ADDRESS(regbuf)
-Define this to extract from an array @var{regbuf} containing the (raw)
-register state, the address in which a function should return its
-structure value, as a CORE_ADDR (or an expression that can be used as
-one).
+When @var{EXTRACT_STRUCT_VALUE_ADDRESS_P} this is used to to extract
+from an array @var{regbuf} (containing the raw register state) the
+address in which a function should return its structure value, as a
+CORE_ADDR (or an expression that can be used as one).
+
+@item EXTRACT_STRUCT_VALUE_ADDRESS_P
+Predicate for @var{EXTRACT_STRUCT_VALUE_ADDRESS}.
@item FLOAT_INFO
If defined, then the `info float' command will print information about
the processor's floating point unit.
@item FP_REGNUM
-The number of the frame pointer register.
+If the virtual frame pointer is kept in a register, then define this
+macro to be the number (greater than or equal to zero) of that register.
+
+This should only need to be defined if @code{TARGET_READ_FP} and
+@code{TARGET_WRITE_FP} are not defined.
-@item FRAMELESS_FUNCTION_INVOCATION(fi, frameless)
-Define this to set the variable @var{frameless} to 1 if the function
-invocation represented by @var{fi} does not have a stack frame
-associated with it. Otherwise set it to 0.
+@item FRAMELESS_FUNCTION_INVOCATION(fi)
+Define this to an expression that returns 1 if the function invocation
+represented by @var{fi} does not have a stack frame associated with it.
+Otherwise return 0.
@item FRAME_ARGS_ADDRESS_CORRECT
stack.c
@var{FRAME_FIND_SAVED_REGS} and @var{EXTRA_FRAME_INFO} are deprecated.
-@item FRAME_NUM_ARGS (val, fi)
-For the frame described by @var{fi}, set @var{val} to the number of arguments
-that are being passed.
+@item FRAME_NUM_ARGS (fi)
+For the frame described by @var{fi} return the number of arguments that
+are being passed. If the number of arguments is not known, return
+@code{-1}.
@item FRAME_SAVED_PC(frame)
Given @var{frame}, return the pc saved there. That is, the return
@code{gcc_compiled.} and @code{gcc2_compiled.}, respectively. (Currently
only defined for the Delta 68.)
+@item GDB_MULTI_ARCH
+If defined and non-zero, enables suport for multiple architectures
+within GDB.
+
+The support can be enabled at two levels. At level one, only
+definitions for previously undefined macros are provided; at level two,
+a multi-arch definition of all architecture dependant macros will be
+defined.
+
@item GDB_TARGET_IS_HPPA
This determines whether horrible kludge code in dbxread.c and
partial-stab.h is used to mangle multiple-symbol-table files from
@item GET_SAVED_REGISTER
Define this if you need to supply your own definition for the function
-@code{get_saved_register}. Currently this is only done for the a29k.
+@code{get_saved_register}.
@item HAVE_REGISTER_WINDOWS
Define this if the target has register windows.
@item PC_REGNUM
If the program counter is kept in a register, then define this macro to
-be the number of that register. This need be defined only if
-@code{TARGET_WRITE_PC} is not defined.
+be the number (greater than or equal to zero) of that register.
+
+This should only need to be defined if @code{TARGET_READ_PC} and
+@code{TARGET_WRITE_PC} are not defined.
@item NPC_REGNUM
The number of the ``next program counter'' register, if defined.
frame.
@item PUSH_ARGUMENTS (nargs, args, sp, struct_return, struct_addr)
-Define this to push arguments onto the stack for inferior function call.
+Define this to push arguments onto the stack for inferior function
+call. Return the updated stack pointer value.
@item PUSH_DUMMY_FRAME
Used in @samp{call_function_by_hand} to create an artificial stack frame.
Return the name of register @var{i} as a string. May return @var{NULL}
or @var{NUL} to indicate that register @var{i} is not valid.
+@item REGISTER_NAMES
+Deprecated in favor of @var{REGISTER_NAME}.
+
@item REG_STRUCT_HAS_ADDR (gcc_p, type)
Define this to return 1 if the given type will be passed by pointer
rather than directly.
(Only used for m88k targets.)
@item SKIP_PROLOGUE (pc)
-A C statement that advances the @var{pc} across any function entry
-prologue instructions so as to reach ``real'' code.
+A C expression that returns the address of the ``real'' code beyond the
+function entry prologue found at @var{pc}.
@item SKIP_PROLOGUE_FRAMELESS_P
-A C statement that should behave similarly, but that can stop as soon as
-the function is known to have a frame. If not defined,
+A C expression that should behave similarly, but that can stop as soon
+as the function is known to have a frame. If not defined,
@code{SKIP_PROLOGUE} will be used instead.
@item SKIP_TRAMPOLINE_CODE (pc)
that is at the start of the real function.
@item SP_REGNUM
-Define this to be the number of the register that serves as the stack
-pointer.
+If the stack-pointer is kept in a register, then define this macro to be
+the number (greater than or equal to zero) of that register.
+
+This should only need to be defined if @code{TARGET_WRITE_SP} and
+@code{TARGET_WRITE_SP} are not defined.
@item STAB_REG_TO_REGNUM
Define this to convert stab register numbers (as gotten from `r'
The default value of the `symbol-reloading' variable. (Never defined in
current sources.)
-@item TARGET_BYTE_ORDER
-The ordering of bytes in the target. This must be defined to be either
-@code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}.
+@item TARGET_BYTE_ORDER_DEFAULT
+The ordering of bytes in the target. This must be either
+@code{BIG_ENDIAN} or @code{LITTLE_ENDIAN}. This macro replaces
+@var{TARGET_BYTE_ORDER} which is deprecated.
+
+@item TARGET_BYTE_ORDER_SELECTABLE_P
+Non-zero if the target has both @code{BIG_ENDIAN} and
+@code{LITTLE_ENDIAN} variants. This macro replaces
+@var{TARGET_BYTE_ORDER_SELECTABLE} which is deprecated.
@item TARGET_CHAR_BIT
Number of bits in a char; defaults to 8.
@item TARGET_COMPLEX_BIT
Number of bits in a complex number; defaults to @code{2 * TARGET_FLOAT_BIT}.
+At present this macro is not used.
+
@item TARGET_DOUBLE_BIT
Number of bits in a double float; defaults to @code{8 * TARGET_CHAR_BIT}.
@item TARGET_DOUBLE_COMPLEX_BIT
Number of bits in a double complex; defaults to @code{2 * TARGET_DOUBLE_BIT}.
+At present this macro is not used.
+
@item TARGET_FLOAT_BIT
Number of bits in a float; defaults to @code{4 * TARGET_CHAR_BIT}.
to unfiltered (``@code{printf}'') output. Symbol reading routines that
print warnings are a good example.
-@section Coding Style
+@section GDB Coding Standards
GDB follows the GNU coding standards, as described in
@file{etc/standards.texi}. This file is also available for anonymous
-FTP from GNU archive sites. There are some additional considerations
-for GDB maintainers that reflect the unique environment and style of GDB
-maintenance. If you follow these guidelines, GDB will be more
-consistent and easier to maintain.
+FTP from GNU archive sites. GDB takes a strict interpretation of the
+standard; in general, when the GNU standard recommends a practice but
+does not require it, GDB requires it.
+
+GDB follows an additional set of coding standards specific to GDB,
+as described in the following sections.
+
+You can configure with @samp{--enable-build-warnings} to get GCC to
+check on a number of these rules. GDB sources ought not to engender any
+complaints, unless they are caused by bogus host systems. (The exact
+set of enabled warnings is currently @samp{-Wall -Wpointer-arith
+-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations}.
+
+@subsection Formatting
-GDB's policy on the use of prototypes is that prototypes are used to
-@emph{declare} functions but never to @emph{define} them. Simple macros
-are used in the declarations, so that a non-ANSI compiler can compile
-GDB without trouble. The simple macro calls are used like this:
+The standard GNU recommendations for formatting must be followed
+strictly.
+
+Note that while in a definition, the function's name must be in column
+zero; in a function declaration, the name must be on the same line as
+the return type.
+
+In addition, there must be a space between a function or macro name and
+the opening parenthesis of its argument list (except for macro
+definitions, as required by C). There must not be a space after an open
+paren/bracket or before a close paren/bracket.
+
+While additional whitespace is generally helpful for reading, do not use
+more than one blank line to separate blocks, and avoid adding whitespace
+after the end of a program line (as of 1/99, some 600 lines had whitespace
+after the semicolon). Excess whitespace causes difficulties for diff and
+patch.
+
+@subsection Comments
+
+The standard GNU requirements on comments must be followed strictly.
+
+Block comments must appear in the following form, with no `/*'- or
+'*/'-only lines, and no leading `*':
@example @code
-extern int memory_remove_breakpoint PARAMS ((CORE_ADDR, char *));
+/* Wait for control to return from inferior to debugger. If inferior
+ gets a signal, we may decide to start it up again instead of
+ returning. That is why there is a loop in this function. When
+ this function actually returns it means the inferior should be left
+ stopped and GDB should read more commands. */
+@end example
+
+(Note that this format is encouraged by Emacs; tabbing for a multi-line
+comment works correctly, and M-Q fills the block consistently.)
+
+Put a blank line between the block comments preceding function or
+variable definitions, and the definition itself.
+
+In general, put function-body comments on lines by themselves, rather
+than trying to fit them into the 20 characters left at the end of a
+line, since either the comment or the code will inevitably get longer
+than will fit, and then somebody will have to move it anyhow.
+
+@subsection C Usage
+
+Code must not depend on the sizes of C data types, the format of the
+host's floating point numbers, the alignment of anything, or the order
+of evaluation of expressions.
+
+Use functions freely. There are only a handful of compute-bound areas
+in GDB that might be affected by the overhead of a function call, mainly
+in symbol reading. Most of GDB's performance is limited by the target
+interface (whether serial line or system call).
+
+However, use functions with moderation. A thousand one-line functions
+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
+@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
described like:
@example @code
-void noprocess PARAMS ((void));
+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. All static functions should have such
-a declaration near the top of their source file.
+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.
-We don't have a gcc option that will properly check that these rules
-have been followed, but it's GDB policy, and we periodically check it
-using the tools available (plus manual labor), and clean up any
-remnants.
+All static functions must be declared in a block near the top of the
+source file.
-@section Clean Design
+@subsection Clean Design
In addition to getting the syntax right, there's the little question of
semantics. Some things are done in certain ways in GDB because long
machines which are radically different don't need to use infptrace.c at
all.
-@emph{Do} write code that doesn't depend on the sizes of C data types,
-the format of the host's floating point numbers, the alignment of anything,
-or the order of evaluation of expressions. In short, follow good
-programming practices for writing portable C code.
-
+Don't put debugging printfs in the code.
@node Porting GDB
@code{makeinfo} will split the document into one overall file and five
or so included files.
+@node Testsuite
+
+@chapter Testsuite
+
+The testsuite is an important component of the GDB package. While it is
+always worthwhile to encourage user testing, in practice this is rarely
+sufficient; users typically use only a small subset of the available
+commands, and it has proven all too common for a change to cause a
+significant regression that went unnoticed for some time.
+
+The GDB testsuite uses the DejaGNU testing framework. DejaGNU is built
+using tcl and expect. The tests themselves are calls to various tcl
+procs; the framework runs all the procs and summarizes the passes and
+fails.
+
+@section Using the Testsuite
+
+To run the testsuite, simply go to the GDB object directory (or to the
+testsuite's objdir) and type @code{make check}. This just sets up some
+environment variables and invokes DejaGNU's @code{runtest} script. While
+the testsuite is running, you'll get mentions of which test file is in use,
+and a mention of any unexpected passes or fails. When the testsuite is
+finished, you'll get a summary that looks like this:
+@example
+ === gdb Summary ===
+
+# of expected passes 6016
+# of unexpected failures 58
+# of unexpected successes 5
+# of expected failures 183
+# of unresolved testcases 3
+# of untested testcases 5
+@end example
+The ideal test run consists of expected passes only; however, reality
+conspires to keep us from this ideal. Unexpected failures indicate
+real problems, whether in GDB or in the testsuite. Expected failures
+are still failures, but ones which have been decided are too hard to
+deal with at the time; for instance, a test case might work everywhere
+except on AIX, and there is no prospect of the AIX case being fixed in
+the near future. Expected failures should not be added lightly, since
+you may be masking serious bugs in GDB. Unexpected successes are expected
+fails that are passing for some reason, while unresolved and untested
+cases often indicate some minor catastrophe, such as the compiler being
+unable to deal with a test program.
+
+When making any significant change to GDB, you should run the testsuite
+before and after the change, to confirm that there are no regressions.
+Note that truly complete testing would require that you run the
+testsuite with all supported configurations and a variety of compilers;
+however this is more than really necessary. In many cases testing with
+a single configuration is sufficient. Other useful options are to test
+one big-endian (Sparc) and one little-endian (x86) host, a cross config
+with a builtin simulator (powerpc-eabi, mips-elf), or a 64-bit host
+(Alpha).
+
+If you add new functionality to GDB, please consider adding tests for it
+as well; this way future GDB hackers can detect and fix their changes
+that break the functionality you added. Similarly, if you fix a bug
+that was not previously reported as a test failure, please add a test
+case for it. Some cases are extremely difficult to test, such as code
+that handles host OS failures or bugs in particular versions of
+compilers, and it's OK not to try to write tests for all of those.
+
+@section Testsuite Organization
+
+The testsuite is entirely contained in @file{gdb/testsuite}. While the
+testsuite includes some makefiles and configury, these are very minimal,
+and used for little besides cleaning up, since the tests themselves
+handle the compilation of the programs that GDB will run. The file
+@file{testsuite/lib/gdb.exp} contains common utility procs useful for
+all GDB tests, while the directory @file{testsuite/config} contains
+configuration-specific files, typically used for special-purpose
+definitions of procs like @code{gdb_load} and @code{gdb_start}.
+
+The tests themselves are to be found in @file{testsuite/gdb.*} and
+subdirectories of those. The names of the test files must always end
+with @file{.exp}. DejaGNU collects the test files by wildcarding
+in the test directories, so both subdirectories and individual files
+get chosen and run in alphabetical order.
+
+The following table lists the main types of subdirectories and what they
+are for. Since DejaGNU finds test files no matter where they are
+located, and since each test file sets up its own compilation and
+execution environment, this organization is simply for convenience and
+intelligibility.
+
+@table @code
+
+@item gdb.base
+
+This is the base testsuite. The tests in it should apply to all
+configurations of GDB (but generic native-only tests may live here).
+The test programs should be in the subset of C that is valid K&R,
+ANSI/ISO, and C++ (ifdefs are allowed if necessary, for instance
+for prototypes).
+
+@item gdb.@var{lang}
+
+Language-specific tests for all languages besides C. Examples are
+@file{gdb.c++} and @file{gdb.java}.
+
+@item gdb.@var{platform}
+
+Non-portable tests. The tests are specific to a specific configuration
+(host or target), such as HP-UX or eCos. Example is @file{gdb.hp}, for
+HP-UX.
+
+@item gdb.@var{compiler}
+
+Tests specific to a particular compiler. As of this writing (June
+1999), there aren't currently any groups of tests in this category that
+couldn't just as sensibly be made platform-specific, but one could
+imagine a gdb.gcc, for tests of GDB's handling of GCC extensions.
+
+@item gdb.@var{subsystem}
+
+Tests that exercise a specific GDB subsystem in more depth. For
+instance, @file{gdb.disasm} exercises various disassemblers, while
+@file{gdb.stabs} tests pathways through the stabs symbol reader.
+
+@end table
+
+@section Writing Tests
+
+In many areas, the GDB tests are already quite comprehensive; you
+should be able to copy existing tests to handle new cases.
+
+You should try to use @code{gdb_test} whenever possible, since it
+includes cases to handle all the unexpected errors that might happen.
+However, it doesn't cost anything to add new test procedures; for
+instance, @file{gdb.base/exprs.exp} defines a @code{test_expr} that
+calls @code{gdb_test} multiple times.
+
+Only use @code{send_gdb} and @code{gdb_expect} when absolutely
+necessary, such as when GDB has several valid responses to a command.
+
+The source language programs do @emph{not} need to be in a consistent
+style. Since GDB is used to debug programs written in many different
+styles, it's worth having a mix of styles in the testsuite; for
+instance, some GDB bugs involving the display of source lines would
+never manifest themselves if the programs used GNU coding style
+uniformly.
+
@node Hints
@chapter Hints
Thanks also for checking in advance about the best way to transfer the
changes.
-The GDB maintainers will only install ``cleanly designed'' patches. You
-may not always agree on what is clean design.
-@c @pxref{Coding Style}, @pxref{Clean Design}.
+The GDB maintainers will only install ``cleanly designed'' patches.
+This manual summarizes what we believe to be clean design for GDB.
If the maintainers don't have time to put the patch in when it arrives,
or if there is any question about a patch, it goes into a large queue
The legal issue is that to incorporate substantial changes requires a
copyright assignment from you and/or your employer, granting ownership
of the changes to the Free Software Foundation. You can get the
-standard document for doing this by sending mail to
-@code{gnu@@prep.ai.mit.edu} and asking for it. I recommend that people
-write in "All programs owned by the Free Software Foundation" as "NAME
-OF PROGRAM", so that changes in many programs (not just GDB, but GAS,
-Emacs, GCC, etc) can be contributed with only one piece of legalese
-pushed through the bureacracy and filed with the FSF. I can't start
-merging changes until this paperwork is received by the FSF (their
-rules, which I follow since I maintain it for them).
+standard documents for doing this by sending mail to @code{gnu@@gnu.org}
+and asking for it. We recommend that people write in "All programs
+owned by the Free Software Foundation" as "NAME OF PROGRAM", so that
+changes in many programs (not just GDB, but GAS, Emacs, GCC, etc) can be
+contributed with only one piece of legalese pushed through the
+bureacracy and filed with the FSF. We can't start merging changes until
+this paperwork is received by the FSF (their rules, which we follow
+since we maintain it for them).
Technically, the easiest way to receive changes is to receive each
-feature as a small context diff or unidiff, suitable for "patch".
-Each message sent to me should include the changes to C code and
-header files for a single feature, plus ChangeLog entries for each
-directory where files were modified, and diffs for any changes needed
-to the manuals (gdb/doc/gdb.texi or gdb/doc/gdbint.texi). If there
-are a lot of changes for a single feature, they can be split down
-into multiple messages.
-
-In this way, if I read and like the feature, I can add it to the
+feature as a small context diff or unidiff, suitable for "patch". Each
+message sent to me should include the changes to C code and header files
+for a single feature, plus ChangeLog entries for each directory where
+files were modified, and diffs for any changes needed to the manuals
+(gdb/doc/gdb.texinfo or gdb/doc/gdbint.texinfo). If there are a lot of
+changes for a single feature, they can be split down into multiple
+messages.
+
+In this way, if we read and like the feature, we can add it to the
sources with a single patch command, do some testing, and check it in.
-If you leave out the ChangeLog, I have to write one. If you leave
-out the doc, I have to puzzle out what needs documenting. Etc.
+If you leave out the ChangeLog, we have to write one. If you leave
+out the doc, we have to puzzle out what needs documenting. Etc.
-The reason to send each change in a separate message is that I will
-not install some of the changes. They'll be returned to you with
-questions or comments. If I'm doing my job, my message back to you
+The reason to send each change in a separate message is that we will not
+install some of the changes. They'll be returned to you with questions
+or comments. If we're doing our job correctly, the message back to you
will say what you have to fix in order to make the change acceptable.
-The reason to have separate messages for separate features is so
-that other changes (which I @emph{am} willing to accept) can be installed
-while one or more changes are being reworked. If multiple features
-are sent in a single message, I tend to not put in the effort to sort
-out the acceptable changes from the unacceptable, so none of the
-features get installed until all are acceptable.
-
-If this sounds painful or authoritarian, well, it is. But I get a lot
-of bug reports and a lot of patches, and most of them don't get
-installed because I don't have the time to finish the job that the bug
+The reason to have separate messages for separate features is so that
+the acceptable changes can be installed while one or more changes are
+being reworked. If multiple features are sent in a single message, we
+tend to not put in the effort to sort out the acceptable changes from
+the unacceptable, so none of the features get installed until all are
+acceptable.
+
+If this sounds painful or authoritarian, well, it is. But we get a lot
+of bug reports and a lot of patches, and many of them don't get
+installed because we don't have the time to finish the job that the bug
reporter or the contributor could have done. Patches that arrive
complete, working, and well designed, tend to get installed on the day
-they arrive. The others go into a queue and get installed if and when
-I scan back over the queue -- which can literally take months
-sometimes. It's in both our interests to make patch installation easy
--- you get your changes installed, and I make some forward progress on
-GDB in a normal 12-hour day (instead of them having to wait until I
-have a 14-hour or 16-hour day to spend cleaning up patches before I
-can install them).
+they arrive. The others go into a queue and get installed as time
+permits, which, since the maintainers have many demands to meet, may not
+be for quite some time.
Please send patches directly to the GDB maintainers at
-@code{gdb-patches@@cygnus.com}.
+@code{gdb-patches@@sourceware.cygnus.com}.
@section Obsolete Conditionals
projects / deliverable / binutils-gdb.git / blobdiff