svn commit: r317094 - head/share/mk

[John Baldwin]

On Thursday, April 20, 2017 09:08:28 AM Rodney W. Grimes wrote:
> > On Wednesday, April 19, 2017 03:51:24 PM Ngie Cooper wrote:
> > > 
> > > > On Apr 19, 2017, at 15:22, Warner Losh <imp at bsdimp.com> wrote:
> > > 
> > > ...
> > > 
> > > >> Actually this is exactly what I would expect from Linux!
> > > >> 
> > > >> Why do we need to pull the trigger on GDB other than to pull the trigger
> > > >> to say we are GPL free, if that is the reason then this is the wrong
> > > >> way to go about it.
> > > > 
> > > > I think "gdb in base is horribly broken" is the real reason. You need
> > > > the port to do anything non-trivial these days.
> 
> Well it seems it can do some rather important trivial things, like post
> mortem process kernel dumps during savecore processing helping users
> submit a kernel panic bugzilla with more than just traceback info.

Only somewhat.  You should actually try to use kgdb and compare it to the
kgdb in ports.

> Removing gdb by calling it a port does not achive the desired goal, it
> simply makes our base system lacking a kernel debugger and oh, you
> have to go install port foo to get back what we have been shipping for
> 25 years, but look, we are GPL free!!  Bullocks.

If we could import GPLv3 code into our tree then /usr/bin/gdb would match
what is in ports (as I would have imported it by now), but that isn't a
viable option due to non-technical issues.

> > > +1 to Warner's sentiments.
> > > 
> > > gdb in base doesn't work well with threads (6.x never did ;/..), and lacks support for other things (like python debugging). Being able to debug threads reliably is a make or break thing.
> > > 
> > > So while I understand and in general agree with you Rod, I completely disagree on the practical end of things. I'm actually kind of curious as to why this isn't being done globally.. but I assume that it was described in one of the many threads some time ago about the status quo for debugging with gdb on tier-two architectures.
> 
> This is not about debugging python or debugging threads, this is about
> kernel panics and post mortem processing of a crash dump so a user can
> submit a more detailed crash than just a trace back from the panic.

Again, you should try to use the tools before arguing the theoretical
point.  Even the stack traces are better with kgdb from ports since it
understands inlined function calls and tail calls that gdb 6.x does not.
Even code generated by gcc-4.2 (much less modern compilers) is easier to
debug with non-ancient gdb.

> > As the commit message stated, gdb in ports doesn't yet include kgdb
> > support for ARM, and no one has tested the sparc64 support for gdb
> > in ports, so those two architectures remain on.  For all other platforms,
> > gdb in ports is a strict superset of gdb in base.
> 
> So in effect we are providing gdb in base for kgdb support
> of ARM and sparc but removing it from i386 and amd64, stopping
> things that worked in the name of what?  This does not make
> us any closer to gpl free, breaks functional stuff, and makes
> us more like Linux and less like FreeBSD (no kernel debugger in
> base system).

We still have DDB in base, so not quite at zero.

> If this is a GPL free issue we could of done this with all the GPL code 20
> years ago... 
> 
> I see no upside to this change, where is the upside?

Because people type in 'gdb' and get an inferior debugging experience
relative to other systems.  Also, /usr/bin/gdb doesn't support 64-bit ARM or
RISCV (and never will).  That support will only be in the ports gdb.  At some
point ARM support for FreeBSD will be upstreamed at which point I will also
add kgdb support to gdb in ports for ARM (which will permit cross-debugging,
something /usr/bin/gdb doesn't do).

For example, if you try to use /usr/bin/gdb on 32-bit MIPS it gets confused
thinking it should use 64-bit registers and gives you utter garbage for
register values.  That makes it 100% useless for kernels, userland, or
anything else.  For 64-bit mips /usr/bin/gdb frequently crashed when I tried
to use it.  We can't pull back fixes from the vendor and I for one am not
going to fork gplv2 GDB and maintain it.  Instead, I've put my time and
effort into adding kernel support to modern GDB and upstreaming support for
MIPS (and probably other platforms in the future) to modern GDB.  Another
route for folks who want to spend time contributing to a solution is to
contribute to lldb.  At the moment it doesn't support floating-point/SSE/AVX
on amd64, doesn't have a framework (even on Linux or OS X) for debugging
across forks, and doesn't have support for several architectures (i386,
mips, riscv, sparc64).  It also doesn't support kernel debugging.

-- 
John Baldwin