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.8
platform.
Package Information
GDB Dependencies
Optional
DejaGnu-1.5.3 (for tests), Doxygen-1.8.10,
Guile-2.0.11, Python-2.7.10, Valgrind-3.10.1, 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.10, 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. First one is that you need
to clean some directories, 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 differences
if run locally or remotely, a large number of timeouts (there is a
variable that can be set to increase time for timeout, but changing
it, apparently the total number of tests is not conserved), there
are failures associated with system readline 6.x, between others. A
few tests assume that the header file <sys/sdt.h>, part of SystemTap, is present.
Unexpected failures are less than 0.3%.
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.10 &&
rm -rf gdb/doc/doxy/xml &&
cp -Rv gdb/doc/doxy /usr/share/doc/gdb-7.10