Merge GDB 7.5.1

gdb/doc/gdbint.info-1

Index: gdb/doc/gdbint.info-1
diff --git a/gdb/doc/gdbint.info-1 b/gdb/doc/gdbint.info-1
index 190fe359d6b476ba8e3950f131bfdabf47874de5..21e048eb0542909c205a599f8166728c86b89254 100644
--- a/gdb/doc/gdbint.info-1
+++ b/gdb/doc/gdbint.info-1
@@ -68,7 +68,8 @@ the mechanisms that adapt GDB to specific hosts and targets.
 
 * GDB Observers::  GDB Currently available observers
 * GNU Free Documentation License::  The license for this documentation
-* Index::
+* Concept Index::
+* Function and Variable Index::
 
 
 File: gdbint.info,  Node: Summary,  Next: Overall Structure,  Prev: Top,  Up: Top
@@ -4462,10 +4463,6 @@ architecture.
      Use this function to convert stab register STAB_REGNR into GDB
      regnum.  If not defined, no conversion will be done.
 
-`SYMBOL_RELOADING_DEFAULT'
-     The default value of the "symbol-reloading" variable.  (Never
-     defined in current sources.)
-
 `TARGET_CHAR_BIT'
      Number of bits in a char; defaults to 8.
 
@@ -5325,6 +5322,21 @@ Use...         ...instead of
 `(foo) x'      `(foo)x'       (cast)
 `*x'           `* x'          (pointer dereference)
 
+   Any two or more lines in code should be wrapped in braces, even if
+they are comments, as they look like separate statements:
+
+     if (i)
+       {
+         /* Return success.  */
+         return 0;
+       }
+
+and not:
+
+     if (i)
+       /* Return success.  */
+       return 0;
+
 16.1.3 Comments
 ---------------
 
@@ -6187,31 +6199,9 @@ performed:
 
         *   file `gdbserver/gdbreplay.c', function `gdbreplay_version'
 
-   * Run the `copyright.sh' script to add the new year in the copyright
-     notices of most source files.  This script requires Emacs 22 or
-     later to be installed.
-
-   * The new year also needs to be added manually in all other files
-     that are not already taken care of by the `copyright.sh' script:
-        *   `*.s'
-
-        *   `*.f'
-
-        *   `*.f90'
-
-        *   `*.igen'
-
-        *   `*.ac'
-
-        *   `*.texi'
-
-        *   `*.texinfo'
-
-        *   `*.tex'
-
-        *   `*.defs'
-
-        *   `*.1'
+   * Run the `copyright.py' Python script to add the new year in the
+     copyright notices of most source files.  This script has been
+     tested with Python 2.6 and 2.7.
 
 
 
@@ -6983,7 +6973,7 @@ Several variables exist to modify the behavior of the testsuite.
      When running the testsuite normally one doesn't want whatever is in
      `~/.gdbinit' to interfere with the tests, therefore the test
      harness passes `-nx' to GDB.  One also doesn't want any windowed
-     version of GDB, e.g., `gdbtui', to run.  This is achieved via
+     version of GDB, e.g., `gdb -tui', to run.  This is achieved via
      `INTERNAL_GDBFLAGS'.
 
           set INTERNAL_GDBFLAGS "-nw -nx"
@@ -7123,6 +7113,96 @@ instance, some GDB bugs involving the display of source lines would
 never manifest themselves if the programs used GNU coding style
 uniformly.
 
+   Some testcase results need more detailed explanation:
+
+`KFAIL'
+     Known problem of GDB itself.  You must specify the GDB bug report
+     number like in these sample tests:
+          kfail "gdb/13392" "continue to marker 2"
+     or
+          setup_kfail gdb/13392 "*-*-*"
+          kfail "continue to marker 2"
+
+`XFAIL'
+     Known problem of environment.  This typically includes GCC but it
+     includes also many other system components which cannot be fixed
+     in the GDB project.  Sample test with sanity check not knowing the
+     specific cause of the problem:
+          # On x86_64 it is commonly about 4MB.
+          if {$stub_size > 25000000} {
+              xfail "stub size $stub_size is too large"
+              return
+          }
+
+     You should provide bug report number for the failing component of
+     the environment, if such bug report is available:
+          if {[test_compiler_info {gcc-[0-3]-*}]
+             || [test_compiler_info {gcc-4-[0-5]-*}]} {
+             setup_xfail "gcc/46955" *-*-*
+          }
+          gdb_test "python print ttype.template_argument(2)" "&C::c"
+
+22.6 Board settings
+===================
+
+In GDB testsuite, the tests can be configured or customized in the board
+file by means of "Board Settings".  Each setting   should be consulted
+by test cases that depend on the corresponding feature.
+
+   Here are the supported board settings:
+
+`gdb,cannot_call_functions'
+     The board does not support inferior call, that is, invoking
+     inferior functions in GDB.
+
+`gdb,can_reverse'
+     The board supports reverse execution.
+
+`gdb,no_hardware_watchpoints'
+     The board does not support hardware watchpoints.
+
+`gdb,nofileio'
+     GDB is unable to intercept target file operations in remote and
+     perform them on the host.
+
+`gdb,noinferiorio'
+     The board is unable to provide I/O capability to the inferior.
+
+`gdb,nosignals'
+     The board does not support signals.
+
+`gdb,skip_huge_test'
+     Skip time-consuming tests on the board with slow connection.
+
+`gdb,skip_float_tests'
+     Skip tests related to float points on target board.
+
+`gdb,use_precord'
+     The board supports process record.
+
+`gdb_server_prog'
+     The location of GDBserver.  If GDBserver somewhere other than its
+     default location is used in test, specify the location of
+     GDBserver in this variable.  The location is a file name of
+     GDBserver that can be either absolute or relative to testsuite
+     subdirectory in build directory.
+
+`in_proc_agent'
+     The location of in-process agent.  If in-process agent other than
+     its default location is used in test, specify the location of
+     in-process agent in this variable.  The location is a file name of
+     in-process agent that can be either  absolute or relative to
+     testsuite subdirectory in build directory.
+
+`noargs'
+     GDB does not support argument passing for inferior.
+
+`no_long_long'
+     The board does not support type `long long'.
+
+`use_gdb_stub'
+     The tests are running with gdb stub.
+
    ---------- Footnotes ----------
 
    (1) If you are using a board file, it could override the test-suite
@@ -7220,107 +7300,3 @@ was wondering if anyone could give me some tips about understanding
 GDB"--if we had some magic secret we would put it in this manual.
 Suggestions for improving the manual are always welcome, of course.
 
-
-File: gdbint.info,  Node: Debugging GDB,  Prev: Getting Started,  Up: Hints
-
-23.2 Debugging GDB with itself
-==============================
-
-If GDB is limping on your machine, this is the preferred way to get it
-fully functional.  Be warned that in some ancient Unix systems, like
-Ultrix 4.2, a program can't be running in one process while it is being
-debugged in another.  Rather than typing the command `./gdb ./gdb',
-which works on Suns and such, you can copy `gdb' to `gdb2' and then
-type `./gdb ./gdb2'.
-
-   When you run GDB in the GDB source directory, it will read a
-`.gdbinit' file that sets up some simple things to make debugging gdb
-easier.  The `info' command, when executed without a subcommand in a
-GDB being debugged by gdb, will pop you back up to the top level gdb.
-See `.gdbinit' for details.
-
-   If you use emacs, you will probably want to do a `make TAGS' after
-you configure your distribution; this will put the machine dependent
-routines for your local machine where they will be accessed first by
-`M-.'
-
-   Also, make sure that you've either compiled GDB with your local cc,
-or have run `fixincludes' if you are compiling with gcc.
-
-23.3 Submitting Patches
-=======================
-
-Thanks for thinking of offering your changes back to the community of
-GDB users.  In general we like to get well designed enhancements.
-Thanks also for checking in advance about the best way to transfer the
-changes.
-
-   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 with everyone else's patches and bug reports.
-
-   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 documents for doing this by sending mail to `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
-bureaucracy 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.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', we have to write one.  If you leave
-out the doc, we have to puzzle out what needs documenting.  Etc., etc.
-
-   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 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 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
-<gdb-patches@sourceware.org>.
-
-23.4 Build Script
-=================
-
-The script `gdb_buildall.sh' builds GDB with flag
-`--enable-targets=all' set.  This builds GDB with all supported targets
-activated.  This helps testing GDB when doing changes that affect more
-than one architecture and is much faster than using `gdb_mbuild.sh'.
-
-   After building GDB the script checks which architectures are
-supported and then switches the current architecture to each of those
-to get information about the architecture.  The test results are stored
-in log files in the directory the script was called from.
-