GDB Debugger Retirement
The gdb in the tree is growing less useful as time passes. As newer version of clang are imported, more features of the compiler must be disabled before gdb will even load with the binaries produced, let alone function. The gdb in ports (both 6.x and 7.x version) works so much better with threads and other modern features. The time has come to retire gdb in the tree and move to a replacement.
Proposed Actions
- Forward port all architecture support to devel/gdb*.
- Port kgdb environment to devel/gdb (and/or have a slave port devel/kgdb)
- Fix the PTRACE issues that require us to have a large threads porting layer
- Bring in lldb, when ready
- Turn off gdb by default
- Remove gdb from tree
Turning off gdb is gated by kgdb support in the port and/or lldb growing kgdb support. Removing gdb from tree is gated by knowing which architectures it breaks and the project consensus being OK with that list.
Discussion
The gdb in the tree is quite ancient. It works well only for C programs that are single threaded. Threaded programs do not work well with it. C++ programs don't work with it. Newer features of C and C++ are poorly supported, if they are supported at all. Keeping gdb in the tree is a liability that grows as we push forward with newer compiler technology.
Removing gdb at this time is undesirable. Even disabling gdb in the build is undesirable because kgdb is so useful still in debugging kernels.
lldb isn't ready for prime time yet. It has achieved basic functionality. Its interface is somewhat different than gdb, the GUI interfaces for it are immature. It hasn't been used in anger in enough situations to shake out the bugs. It does not support kgdb functionality at all. While it has a promising future, it is not ready to take over for even our aging gdb.
The kgdb functionality has not been ported to the devel/gdb* ports yet. This is a critical feature for any replacement that we must have in some shape. Forward porting is straight forward, but not a drop in. Newer gdb also offers better scripting support.
The FreeBSD specific architecture support in the ports is currently disabled for arm, mips, sparc64 and ia64, at least for gdb 7.6.2. The current state of the port is unknown for those architectures. Deciding to force the use of a port without even knowing the status of all the ports is unwise. Specific testing is desirable, even if the result is total fail.
It is highly desirable to disable gdb in 11.0-release, and remove it before 12.0-release.
Testing/Porting Information
Task |
owner |
Status |
Port kgdb to devel/gdb |
done |
|
Test devel/gdb on arm v4 |
none |
Unknown, please test |
Test devel/gdb on arm v6 |
none |
Unknown, please test |
Test devel/gdb on arm v6, hard float |
none |
Unknown, please test |
Test devel/gdb on big endian mips 32 bit |
none |
Unknown, please test |
Test devel/gdb on little endian mips 32 bit |
none |
Unknown, please test |
Test devel/gdb on big endian mips 64 bit |
none |
Unknown, please test |
Test devel/gdb on big endian mips n32 bit (any users?) |
none |
Unknown, please test |
Test devel/gdb on little endian mips 64 bit (any users?) |
none |
Unknown, please test |
Test devel/gdb on sparc64 |
Only compiles if THREADS option disabled |
|
Test devel/gdb on powerpc 32bit |
working |
|
Test devel/gdb on powerpc 64bit |
working |
|
Test devel/gdb on i386 |
none |
working |
Test devel/gdb on amd64 |
none |
working |
Fix ptrace for threads |
none |
needs work, current kludges difficult to forward port |
devel/gdb supports all current FreeBSD architectures |
none |
Waiting for testing results, and maybe actual work |
Disable gdb build by default in current |
Done |
|
Remove gdb from tree |
Done |
|
bring in lldb |
In progress, but lldb needs to mature to support kgdb |
Testing Information
To test the GDB port, run make test in devel/gdb
This runs the gdb test suite and gives you an impression of the port. (TODO: testsuite/lib/gdb.exp fix -ldl, not needed on fbsd)
At the moment, only i386/amd64, powerpc/powerpc64 and sparc64 have the support in the gdb trunk sources.
ARM is WIP.