( Debugging

Info Catalog ( Efficiency ( GMP Basics ( Profiling
 Stack Overflow
      Depending on the system, a segmentation violation or bus error
      might be the only indication of stack overflow.  See
      `--enable-alloca' choices in  Build Options, for how to
      address this.
      In new enough versions of GCC, `-fstack-check' may be able to
      ensure an overflow is recognised by the system before too much
      damage is done, or `-fstack-limit-symbol' or
      `-fstack-limit-register' may be able to add checking if the system
      itself doesn't do any ( Options for Code Generation
      (gcc)Code Gen Options.).  These options must be added to the
      `CFLAGS' used in the GMP build ( Build Options), adding
      them just to an application will have no effect.  Note also
      they're a slowdown, adding overhead to each function call and each
      stack allocation.
 Heap Problems
      The most likely cause of application problems with GMP is heap
      corruption.  Failing to `init' GMP variables will have
      unpredictable effects, and corruption arising elsewhere in a
      program may well affect GMP.  Initializing GMP variables more than
      once or failing to clear them will cause memory leaks.
      In all such cases a `malloc' debugger is recommended.  On a GNU or
      BSD system the standard C library `malloc' has some diagnostic
      facilities, see  Allocation Debugging (libc)Allocation
      Debugging, or `man 3 malloc'.  Other possibilities, in no
      particular order, include
           `'  (electric fence)
      The GMP default allocation routines in `memory.c' also have a
      simple sentinel scheme which can be enabled with `#define DEBUG'
      in that file.  This is mainly designed for detecting buffer
      overruns during GMP development, but might find other uses.
 Stack Backtraces
      On some systems the compiler options GMP uses by default can
      interfere with debugging.  In particular on x86 and 68k systems
      `-fomit-frame-pointer' is used and this generally inhibits stack
      backtracing.  Recompiling without such options may help while
      debugging, though the usual caveats about it potentially moving a
      memory problem or hiding a compiler bug will apply.
 GDB, the GNU Debugger
      A sample `.gdbinit' is included in the distribution, showing how
      to call some undocumented dump functions to print GMP variables
      from within GDB.  Note that these functions shouldn't be used in
      final application code since they're undocumented and may be
      subject to incompatible changes in future versions of GMP.
 Source File Paths
      GMP has multiple source files with the same name, in different
      directories.  For example `mpz', `mpq' and `mpf' each have an
      `init.c'.  If the debugger can't already determine the right one
      it may help to build with absolute paths on each C file.  One way
      to do that is to use a separate object directory with an absolute
      path to the source directory.
           cd /my/build/dir
      This works via `VPATH', and might require GNU `make'.  Alternately
      it might be possible to change the `.c.lo' rules appropriately.
 Assertion Checking
      The build option `--enable-assert' is available to add some
      consistency checks to the library (see  Build Options).
      These are likely to be of limited value to most applications.
      Assertion failures are just as likely to indicate memory
      corruption as a library or compiler bug.
      Applications using the low-level `mpn' functions, however, will
      benefit from `--enable-assert' since it adds checks on the
      parameters of most such functions, many of which have subtle
      restrictions on their usage.  Note however that only the generic C
      code has checks, not the assembler code, so CPU `none' should be
      used for maximum checking.
 Temporary Memory Checking
      The build option `--enable-alloca=debug' arranges that each block
      of temporary memory in GMP is allocated with a separate call to
      `malloc' (or the allocation function set with
      This can help a malloc debugger detect accesses outside the
      intended bounds, or detect memory not released.  In a normal
      build, on the other hand, temporary memory is allocated in blocks
      which GMP divides up for its own use, or may be allocated with a
      compiler builtin `alloca' which will go nowhere near any malloc
      debugger hooks.
 Maximum Debuggability
      To summarize the above, a GMP build for maximum debuggability
      would be
           ./configure --disable-shared --enable-assert \
             --enable-alloca=debug --host=none CFLAGS=-g
      For C++, add `--enable-cxx CXXFLAGS=-g'.
      The GCC checker (`') can
      be used with GMP.  It contains a stub library which means GMP
      applications compiled with checker can use a normal GMP build.
      A build of GMP with checking within GMP itself can be made.  This
      will run very very slowly.  On GNU/Linux for example,
           ./configure --host=none-pc-linux-gnu CC=checkergcc
      `--host=none' must be used, since the GMP assembler code doesn't
      support the checking scheme.  The GMP C++ features cannot be used,
      since current versions of checker ( don't yet support the
      standard C++ library.
      The valgrind program (`') is a memory checker
      for x86s.  It translates and emulates machine instructions to do
      strong checks for uninitialized data (at the level of individual
      bits), memory accesses through bad pointers, and memory leaks.
      Recent versions of Valgrind are getting support for MMX and
      SSE/SSE2 instructions, for past versions GMP will need to be
      configured not to use those, ie. for an x86 without them (for
      instance plain `i486').
 Other Problems
      Any suspected bug in GMP itself should be isolated to make sure
      it's not an application problem, see  Reporting Bugs.
Info Catalog ( Efficiency ( GMP Basics ( Profiling
automatically generated byinfo2html