Retiring in-tree GDB

[John Baldwin]

On Wednesday, July 20, 2016 02:39:55 PM Warner Losh wrote:
> 
> > On Jul 20, 2016, at 2:19 PM, John Baldwin <jhb at freebsd.org> wrote:
> > 
> > On Wednesday, July 20, 2016 01:20:34 PM Sean Bruno wrote:
> >> 
> >> On 07/20/16 13:00, John Baldwin wrote:
> >>> On Tuesday, October 20, 2015 01:36:28 PM John Baldwin wrote:
> >>>> When this topic was last raised (by Warner I believe), the primary objection
> >>>> (certainly my main one) was that the in-tree kgdb was the only kernel debugger
> >>>> available.  kgdb is now available via the devel/gdb port in ports (and as of
> >>>> last week was enabled by default, so 'pkg install gdb' will get you a kgdb
> >>>> binary).  The kgdb in ports is in general superior to the one in the base
> >>>> system.  It is a cross debugger by default (and with my pending patches to
> >>>> libkvm it even supports cross debugging of vmcores).
> >>>> 
> >>>> There are some issues still with devel/gdb: namely it does not currently
> >>>> support some of the platforms supported by our in tree gdb such as arm and
> >>>> mips.  For these platforms I think the in-tree gdb will need to remain until
> >>>> there is a suitable alternative.
> >>>> 
> >>>> However, I would like to propose that we retire the in-tree GDB for some of
> >>>> our platforms (namely x86) for 11.  In particular, I think we should default
> >>>> to enabling lldb and disabling gdb for platforms that meet the following
> >>>> criteria:
> >>>> 
> >>>> 1) devel/gdb works including thread and kgdb support
> >>>> 2) lldb works
> >>>> 
> >>>> We could perhaps be more aggressive and handle lldb and gdb toggles
> >>>> independently, but I think we want to ship some sort of userland debugger
> >>>> out of the box on all of our platforms.  The question I think might be if
> >>>> we end up with platforms where 1) is true but 2) is not (such as powerpc).
> >>>> 
> >>>> I believe that these conditions are only true for x86 currently.
> >>>> 
> >>>> Comments?
> >>> 
> >>> I believe I've fixed the one last thing that was depending on /usr/bin/gdb
> >>> (crashinfo) to use devel/gdb if it is present.  I'd either like to disable
> >>> the base gdb on amd64 in the next week or so on HEAD, or perhaps if people are
> >>> really gutsy, disable it for all platforms on HEAD.  We still don't have kgdb
> >>> in ports for non-x86 (though for ppc at least kgdb in ports and base is
> >>> equally dysfunctional).
> >>> 
> >>> However, to start with:
> >>> 
> >>> 1) Does anyone have a reason to keep /usr/bin/gdb on amd64?
> >>> 
> >>> 2) Does anyone have a reason to keep /usr/bin/gdb on !amd64?
> >>> 
> >> 
> >> I don't have an immediate use case in the mips/mips64 case.  Should
> >> ports "just work" here or do I need some kind of "cross gdb"?
> > 
> > ports gdb does not yet work on mips.  Once it supports mips it will work as
> > both a native and cross debugger, but it just doesn't know about FreeBSD/mips
> > at all.  Does /usr/bin/gdb work on mips?
> 
> It does, kinda. there’s a lot of stuff it gets right, so it can be useful. However,
> there’s enough wrong that it’s super frustrating. So there’s a low bar to
> replacement. If I can build a new /bin/cat and debug it with a ports gdb,
> even if things are broken that kinda work now, I’m all for replacement.
> 
> If /usr/bin/gdb were super duper cool on mips, I’d have a different take, but
> gdb on mips has never been stellar.

Well, devel/gdb won't work at all on mips, so if we removed /usr/bin/gdb on all
platforms you'd be left with no debugger at all.  Starting with amd64 is probably
the most prudent for now.  i386 is probably also a good candidate even without
working lldb.

-- 
John Baldwin