Date: Thu, 10 Apr 2014 14:37:17 -0600 From: Warner Losh <imp@bsdimp.com> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-arch@freebsd.org Subject: Re: Time for turning off gdb by default? Or worse... Message-ID: <674B7C0B-9235-4030-9A44-7F9984CA2F67@bsdimp.com> In-Reply-To: <201404091145.58792.jhb@freebsd.org> References: <DD38131E-9A43-4EFA-A27D-ED6B64F6A35A@bsdimp.com> <201404091145.58792.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
OK. Here=92s 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=85
(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=92ve 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=92s =
feedback. Feel free to comment on the wiki page or edit it for missing =
items (or testing you=92ve done).
At this point, I=92m withdrawing the gdb disabled by default patches.
Warner
On Apr 9, 2014, at 9:45 AM, John Baldwin <jhb@FreeBSD.org> wrote:
> On Tuesday, April 08, 2014 4:34:35 pm Warner Losh wrote:
>> Greetings,
>>=20
>> The gdb in the tree seems to be of very limited usefulness these =
days. It
>> doesn=92t seem to work on clang-enabled architectures w/o building =
-gdwarf-2,
>> it doesn=92t seem to work with threaded applications, and on some
>> architectures it doesn=92t seem to work at all (mips comes to mind, =
but it may
>> have been the two binaries I tried).
>>=20
>> It seems like we=92d be doing our users a favor by applying:
>>=20
>> 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=3D
>> FREEBSD_UPDATE \
>> GAMES \
>> GCOV \
>> - GDB \
>> GNU \
>> GNU_GREP_COMPAT \
>> GPIB \
>> @@ -355,6 +354,7 @@ WITH_HESIOD=3D
>> CLANG_EXTRAS \
>> CTF \
>> DEBUG_FILES \
>> + GDB \
>> HESIOD \
>> INSTALL_AS_USER \
>> LLDB \
>>=20
>> to the tree, which will turn gdb off by default. It may make more =
sense to
>> just remove it entirely, but I=92m not sure I want to go there just =
yet in
>> case there are things that I=92m missing. I believe that the port =
will be
>> adequate for all architectures we support, but haven=92t tested this =
directly
>> yet. I do know that on amd64, the port just worked, where the in-tree =
gdb
>> was an epic fail.
>=20
> 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:
>=20
> 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)
>=20
> 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.
>=20
> 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.
>=20
> --=20
> John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?674B7C0B-9235-4030-9A44-7F9984CA2F67>