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.

  1. Forward port all architecture support to devel/gdb*.
  2. Port kgdb environment to devel/gdb (and/or have a slave port devel/kgdb)
  3. Fix the PTRACE issues that require us to have a large threads porting layer
  4. Bring in lldb, when ready
  5. Turn off gdb by default
  6. 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.

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.

Task owner Status
Port kgdb to devel/gdb JohnBaldwin 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 MarkLinimon Only compiles if THREADS option disabled
Test devel/gdb on powerpc 32bit AndreasTobler working
Test devel/gdb on powerpc 64bit AndreasTobler 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 EdMaste Done
Remove gdb from tree EdMaste Done
bring in lldb EdMaste In progress, but lldb needs to mature to support kgdb

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.


  • gdbretirement.txt
  • Last modified: 2026/10/12 10:55
  • (external edit)