svn commit: r317094 - head/share/mk

[Rodney W. Grimes]

> 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.

Lets see.. we need to ship a full set of kernel symbols with a distribution,
but now we are gona rip out the debugger??? 

> > > Plus core set this as a goal for the project after it was clear that
> > > was a consensus desire several years ago. Can't fault someone for
> > > working towards that goal.

I do not think Core set this as a goal, the developers did it at a summit,
and that was really only adding "by 12.0" to a goal that has been with the
project since... well..  1.0!

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.

> > +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.

> 
> 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).

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?
-- 
Rod Grimes                                                 rgrimes at freebsd.org