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

[Warner Losh]

OK. Here’s the summary of the thread:

(1) gdb in tree is ancient
(2) kgdb is quite useful, and only in tree
(3) ports gdb rocks, but…
(4) ports gdb exists only for a few architectures
(5) Fixing ptrace will allow us to use a more-stock gdb

Action items:

(1) Create a wiki page with timeline to deactivation and removal.
(2) Create milestones along the path for
     (a) kgdb + devel/gdb*
     (b) architectural coverage
     (c) ptrace fixes
(3) profit.

I’ve done these steps and documented them at https://wiki.freebsd.org/GdbRetirement to allow work to progress (or not) without repeating this discussion. Thanks for everybody’s feedback. Feel free to comment on the wiki page or edit it for missing items (or testing you’ve done).

At this point, I’m withdrawing the gdb disabled by default patches.

Warner


On Apr 9, 2014, at 9:45 AM, John Baldwin <jhb at FreeBSD.org> wrote:

> 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