Introduction to GDB
GDB, the GNU Project debugger,
allows you to see what is going on “inside” another program while it executes --
or what another program was doing at the moment it crashed. Note
that GDB is most effective when
tracing programs and libraries that were built with debugging
symbols and not stripped.
This package is known to build and work properly using an LFS
DejaGnu-1.5.3 (for tests), Doxygen-1.8.11,
Guile-2.0.11, Python-2.7.11, Valgrind-3.11.0, and SystemTap (run-time
dependency, also used in a few tests)
User Notes: http://wiki.linuxfromscratch.org/blfs/wiki/gdb
Installation of GDB
Install GDB by running the
./configure --prefix=/usr --with-system-readline &&
Optionally, to build the API documentation using Doxygen-1.8.11, run:
make -C gdb/doc doxy
To test the results, issue:
pushd gdb/testsuite &&
make site.exp &&
echo "set gdb_test_timeout 120" >> site.exp &&
See gdb/testsuite/README and
are many problems with the test suite:
Clean directories ire needed if re-running the tests. For
that reason, it is recommended to make a copy of the compiled
source code directory before the tests in case you need to
run the tests again.
Results depend on installed compilers.
If run remotely over an ssh connection, the tests will hang
and require a hard (power cycle) reset of the sytem.
There are a large number of timeouts (there is a variable
that can be set to increase time for timeout, but changing it
will result in a different number of tests being run.
There are failures associated with system readline 6.x.
A few tests assume that the header file
<sys/sdt.h>, part of SystemTap, is
About 3% of the tests fail (out of over 35000 tests).
Now, as the
make -C gdb install
If you have built the API documentation, it is now in gdb/doc/doxy.
You can install it (as the
install -d /usr/share/doc/gdb-7.11 &&
rm -rf gdb/doc/doxy/xml &&
cp -Rv gdb/doc/doxy /usr/share/doc/gdb-7.11