Time for turning off gdb by default? Or worse...

[John Baldwin]

On Tuesday, April 08, 2014 4:34:35 pm Warner Losh wrote:
> Greetings,
> 
> The gdb in the tree seems to be of very limited usefulness these days. It
> doesn’t seem to work on clang-enabled architectures w/o building -gdwarf-2,
> it doesn’t seem to work with threaded applications, and on some
> architectures it doesn’t seem to work at all (mips comes to mind, but it may
> have been the two binaries I tried).
> 
> It seems like we’d be doing our users a favor by applying:
> 
> diff -r 8bfca9de870e share/mk/bsd.own.mk
> --- a/share/mk/bsd.own.mk
> +++ b/share/mk/bsd.own.mk
> @@ -266,7 +266,6 @@ WITH_HESIOD=
>      FREEBSD_UPDATE \
>      GAMES \
>      GCOV \
> -    GDB \
>      GNU \
>      GNU_GREP_COMPAT \
>      GPIB \
> @@ -355,6 +354,7 @@ WITH_HESIOD=
>      CLANG_EXTRAS \
>      CTF \
>      DEBUG_FILES \
> +    GDB \
>      HESIOD \
>      INSTALL_AS_USER \
>      LLDB \
> 
> to the tree, which will turn gdb off by default. It may make more sense to
> just remove it entirely, but I’m not sure I want to go there just yet in
> case there are things that I’m missing. I believe that the port will be
> adequate for all architectures we support, but haven’t tested this directly
> yet. I do know that on amd64, the port just worked, where the in-tree gdb
> was an epic fail.

kgdb is a must.  I think it would be less work to forward port kgdb support
into gdb7 from ports than to keep our ancient gdb alive.  Some things I can
think of for gdb7:

 1) The threads patch could be greatly simplified if we fixed the ptrace
    backend to properly handle inferiors with tids.  This would remove a
    lot of the threads patch where the thread inferior tries to invoke
    ptrace directly and convert registers, etc.  The way it does this now
    is a total hack and requires much larger patches.  This would also
    make it a lot easier to get thread debugging working on more
    architectures as the thread-db bits would become mostly MI (if not
    entirely)

 2) Porting the kgdb frontend to work with gdb7.  It would be nicer to
    have a more modern base for kgdb and the ability to use python
    scripting with kgdb, custom printers for in-kernel structures, etc.

I think if we have a useful devel/kgdb that builds against devel/gdb we
can probably think about retiring gdb<ancient>, but it's premature right
now.

-- 
John Baldwin