Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Apr 2017 16:22:39 -0600
From:      Warner Losh <imp@bsdimp.com>
To:        rgrimes@freebsd.org
Cc:        Eric van Gyzen <vangyzen@freebsd.org>, John Baldwin <jhb@freebsd.org>,  Slawa Olhovchenkov <slw@zxy.spb.ru>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>,  "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, src-committers <src-committers@freebsd.org>
Subject:   Re: svn commit: r317094 - head/share/mk
Message-ID:  <CANCZdfqkkEyKi5No7YQ7jmASTXZd6v1bha%2Bb=-rquULtmde9pw@mail.gmail.com>
In-Reply-To: <201704192218.v3JMIYtS032774@pdx.rh.CN85.dnsmgr.net>
References:  <c8fd3b81-f423-81c2-1ae1-45507c7f70f2@FreeBSD.org> <201704192218.v3JMIYtS032774@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Apr 19, 2017 at 4:18 PM, Rodney W. Grimes
<freebsd@pdx.rh.cn85.dnsmgr.net> wrote:
> [ Charset windows-1252 unsupported, converting... ]
>> >>>>> 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.
>> >
>> > Yes, I know we want to get gnu stuff out of the tree, but that needs
>> > to come AFTER a proper replacement is avaliable.
>> >
>> >>
>> >>> Also, how to generate core.txt after crash, reboot and install gdb
>> >>> from ports? (port instaled after crash)
>> >>
>> >> You can always run crashinfo by hand.
>> >
>> > /me starts to look for a new OS, this one is not very good at user support.
>>
>> # crashinfo
>> Please install GDB and run 'crashinfo' again.
>> The easiest way to install GDB is: pkg install gdb
>> Unable to find matching kernel for /var/crash/vmcore.1
>>
>> https://reviews.freebsd.org/D10429
>>
>> This should be good enough to keep the user from looking for a new OS.
>> It also gets a much better version of GDB onto the box, which will make
>> the user happier than giving them an ancient one and letting them flail
>> around with it for a while before learning that they should install a
>> newer one.
>
> 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.

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.

> As I said, pull the trigger when you have a new tool in base to replace
> what I have  expected to be in base, have been using in base for 2.5
> decades, and not a day before.
>
> Your fixing a single point issue, crashinfo, where is my debugger, and
> why cant it do the crashinfo stuff???

Things break with progress. That's always been true. We lost
functionality when we kicked perl and TCL out of the tree. We lost
functionality when we kicked sysinstall to the curb, etc. However,
we've also gained functionality as well with things like clang. It's
always balancing act. I think we've bent over too far backwards with
gdb, and it's time to kick it to the curb entirely.

Warner



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqkkEyKi5No7YQ7jmASTXZd6v1bha%2Bb=-rquULtmde9pw>