Merge GDB 7.5.1

gdb/doc/gdbint.info-1

 This is gdbint.info, produced by makeinfo version 4.8 from
 ./gdbint.texinfo.
 
 INFO-DIR-SECTION Software development
 START-INFO-DIR-ENTRY
 * Gdb-Internals: (gdbint).      The GNU debugger's internals.
 END-INFO-DIR-ENTRY
 
    Copyright (C) 1990-1994, 1996, 1998-2006, 2008-2012 Free Software
 Foundation, Inc.  Contributed by Cygnus Solutions.  Written by John
@@ skipping 50 matching lines @@
 * Misc Guidelines::
 * Porting GDB::
 * Versions and Branches::
 * Start of New Year Procedure::
 * Releasing GDB::
 * Testsuite::
 * Hints::
 
 * 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
 
 1 Summary
 *********
 
 * Menu:
 
 * Requirements::
@@ skipping 4373 matching lines @@
      to return a new PC that is at the start of the real function.
 
 `int gdbarch_deprecated_fp_regnum (GDBARCH)'
      If the frame pointer is in a register, use this function to return
      the number of that register.
 
 `int gdbarch_stab_reg_to_regnum (GDBARCH, STAB_REGNR)'
      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.
 
 `int gdbarch_char_signed (GDBARCH)'
      Non-zero if `char' is normally signed on this architecture; zero if
      it should be unsigned.
 
      The ISO C standard requires the compiler to treat `char' as
      equivalent to either `signed char' or `unsigned char'; any
      character in the standard execution set is supposed to be positive.
@@ skipping 839 matching lines @@
    In addition, whitespace around casts and unary operators should
 follow the following guidelines:
 
 Use...         ...instead of  
 `!x'           `! x'          
 `~x'           `~ x'          
 `-x'           `- x'          (unary minus)
 `(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
 ---------------
 
 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 `*':
 
      /* Wait for control to return from inferior to debugger.  If inferior
         gets a signal, we may decide to start it up again instead of
@@ skipping 842 matching lines @@
 
    * Update the copyright year in the startup message
 
      Update the copyright year in:
         *   file `top.c', function `print_gdb_version'
 
         *   file `gdbserver/server.c', function `gdbserver_version'
 
         *   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.
 
 
 
 File: gdbint.info,  Node: Releasing GDB,  Next: Testsuite,  Prev: Start of New Year Procedure,  Up: Top
 
 21 Releasing GDB
 ****************
 
 21.1 Branch Commit Policy
 =========================
@@ skipping 751 matching lines @@
      When testing a different GDB, it is often useful to also test a
      different gdbserver.
 
           make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver"
 
    * `INTERNAL_GDBFLAGS'
 
      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"
 
      This is all well and good, except when testing an installed GDB
      that has been configured with `--with-system-gdbinit'.  Here one
      does not want `~/.gdbinit' loaded but one may want the system
      `.gdbinit' file loaded.  This can be achieved by pointing `$HOME'
      at a directory without a `.gdbinit' and by overriding
      `INTERNAL_GDBFLAGS' and removing `-nx'.
@@ skipping 119 matching lines @@
 On some operating systems (e.g. OpenBSD) the TTY layer expands tabs to
 spaces, so by the time GDB's output reaches expect the tab is gone.
 
    The source language programs do _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.
 
+   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
 default; search the board file for "timeout".
 
 
 File: gdbint.info,  Node: Hints,  Next: GDB Observers,  Prev: Testsuite,  Up: Top
 
 23 Hints
 ********
@@ skipping 77 matching lines @@
 `info display' command invokes `display_info'.  When this convention is
 not followed, you might have to use `grep' or `M-x tags-search' in
 emacs, or run GDB on itself and set a breakpoint in `execute_command'.
 
    If all of the above fail, it may be appropriate to ask for
 information on `bug-gdb'.  But _never_ post a generic question like "I
 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.
-