svn commit: r317094 - head/share/mk

John Baldwin jhb at freebsd.org
Thu Apr 20 07:31:17 UTC 2017


On Wednesday, April 19, 2017 09:33:32 AM Rodney W. Grimes wrote:
> > On Wednesday, April 19, 2017 01:28:37 AM Slawa Olhovchenkov wrote:
> > > On Tue, Apr 18, 2017 at 12:45:25PM -0700, John Baldwin wrote:
> > > 
> > > > On Tuesday, April 18, 2017 07:30:13 PM Slawa Olhovchenkov wrote:
> > > > > On Tue, Apr 18, 2017 at 04:27:48PM +0000, John Baldwin wrote:
> > > > > 
> > > > > > Author: jhb
> > > > > > Date: Tue Apr 18 16:27:48 2017
> > > > > > New Revision: 317094
> > > > > > URL: https://svnweb.freebsd.org/changeset/base/317094
> > > > > > 
> > > > > > Log:
> > > > > >   Disable in-tree GDB by default on x86, mips, and powerpc.
> > > > > >   
> > > > > >   GDB in ports contains all of the functionality as GDB in base
> > > > > >   (including kgdb) for these platforms along with additional
> > > > > >   functionality.  In-tree GDB remains enabled on ARM and sparc64.
> > > > > >   GDB in ports does not currently support kernel debugging on arm,
> > > > > >   and ports GDB for sparc64 has not been tested (though it does
> > > > > >   include sparc64 support).
> > > > > >   
> > > > > >   Reviewed by:	bdrewery, emaste, imp
> > > > > >   Relnotes:	yes
> > > > > >   Sponsored by:	DARPA / AFRL
> > > > > >   Differential Revision:	https://reviews.freebsd.org/D10399
> > > > > 
> > > > > Generating core.txt now complety broken?
> > > > 
> > > > No.  crashinfo has supported gdb from ports for quite a while now.
> > > > If you 'pkg install gdb' crashinfo defaults to using the ports gdb over
> > > > the base one already.
> > > 
> > > I am about clean install, w/o ports.
> > 
> > Until we get some sort of klldb support that will not work.  However,
> > we already have platforms now where /usr/bin/gdb doesn't work for that.
> > riscv and aarch64 aren't supported in ancient gdb, and the MIPS
> > /usr/bin/gdb didn't really work for me in my testing.
> 
> So we break what worked on a Tier1 Platform?  With my "user" hat on
> these are the exact kind of breakages that send me looking for another
> platform to run on.  We far to often just go oh you can do X y and Z
> to get around what we broke forgetting that the user 6 months from now
> when this hits a release isnt gona come ask, he may just go down the
> road to something else.
> 
> Remove gdb WHEN klldb can replace it, not a day before.  Using "oh its
> broken on aarch64 and mips" is not a reason to break things on i386/amd64.

/usr/bin/gdb is replaced by gdb from ports.  /usr/bin/gdb in base will
never get updated and will continue to rot.  gdb from ports includes
full kgdb support (and crashinfo will use it when available).  gdb from
ports also includes things like handling inline functions, AVX, fork
following, support for threads for compat32 binaries, and cross-debugging
of crash dumps (so you can debug a MIPS vmcore on an amd64 host) which
/usr/bin/gdb will never be able to do.

> Yes, I know we want to get gnu stuff out of the tree, but that needs
> to come AFTER a proper replacement is avaliable.

In this case the replacement is available as a package.  GPLv2 gdb is
orphaned and not maintained by anyone.

-- 
John Baldwin


More information about the svn-src-head mailing list