Re: Removing obsolete GDB 6.1.1 for FreeBSD 13

On Wed, Dec 2, 2020 at 10:44 AM Ed Maste <emaste_at_freebsd.org> wrote:

> We currently have an obsolete version of GDB 6.1 installed as
> /usr/libexec/gdb, kept only for use by crashinfo(8), which extracts
> some basic information from a kernel core dump after a crash. If the
> gdb port is installed crashinfo will use that in preference to
> /usr/libexec/gdb. If neither exists it will not perform any analysis,
> reporting "Unable to find a kernel debugger."
>
> GDB 6.1.1 was released in June 2004 and is long obsolete. It does not
> support all of the architectures that FreeBSD does, and imposes
> limitations on the FreeBSD kernel build - the continued use of DWARF2.
>
> I would like to remove GDB 6.1.1 before FreeBSD 13, and propose to
> switch the GDB knob to default to NO in the near future. If the
> crashinfo utility and related man pages do not already include
> references to installing the gdb port/package I will add those before
> making the change.
>
> In the fullness of time we may use LLDB to extract the same
> information, or provide other tooling to do so, but I do not want to
> block GDB 6.1.1's removal on this.
>
> Please let me know of any objections or comments.
>

I fully support this action. We kept gdb on board for 12 (and 11?) for
crashinfo as a transition to the new gdb port and to help smooth over bumps
from moving kgdb support into that port. jhb_at_ has done a great job in
getting kgdb moved into the port. I use the port exclusively these days for
all the kernel debugging I have to do from panics in our fleet (although I
have some minorly special needs so I use a special script to fit into our
buildenv vs deployed env). The current gdb in the base can't cope with
anything more complicated than 'hello world'. It's broken for threads. It's
broken for much of the code clang generates. It's useless for kernel dumps
(even tracebacks are unreliable in my experience). There's little to no
value that having gdb in the tree at this point.

I also agree that none of this should be gated on lldb. gdb in tree is so
out of date that we are much better off removing it, even if lldb isn't a
complete drop in replacement (I've not used it at all, so I can't say one
way or another).

Warner