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-7.10
platform.
Package Information
GDB Dependencies
Optional
DejaGnu-1.6 (for tests), Doxygen-1.8.11, Guile-2.0.12,
Python-2.7.12, 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
following commands:
./configure --prefix=/usr --with-system-readline &&
make
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 &&
runtest TRANSCRIPT=y
popd
See gdb/testsuite/README and
TestingGDB. There
are many problems with the test suite:
-
Clean directories are 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.
-
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
present.
-
About 3% of the tests fail (out of over 35000 tests).
Now, as the root user:
make -C gdb install
If you have built the API documentation, it is now in gdb/doc/doxy.
You can install it (as the root
user):
install -d /usr/share/doc/gdb-7.11.1 &&
rm -rf gdb/doc/doxy/xml &&
cp -Rv gdb/doc/doxy /usr/share/doc/gdb-7.11.1