Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 19 Apr 2017 18:04:12 -0500
From:      Pedro Giffuni <pfg@FreeBSD.org>
To:        rgrimes@FreeBSD.org, Eric van Gyzen <vangyzen@FreeBSD.org>
Cc:        John Baldwin <jhb@FreeBSD.org>, Slawa Olhovchenkov <slw@zxy.spb.ru>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org
Subject:   Re: svn commit: r317094 - head/share/mk
Message-ID:  <acbffc5a-f17f-5077-f9f0-46b9640ba115@FreeBSD.org>
In-Reply-To: <201704192218.v3JMIYtS032774@pdx.rh.CN85.dnsmgr.net>
References:  <201704192218.v3JMIYtS032774@pdx.rh.CN85.dnsmgr.net>

next in thread | previous in thread | raw e-mail | index | archive | help

On 19/4/2017 17:18, Rodney W. Grimes 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!

Does linux include a kernel debugger now? Last I heard Linus was against 
debuggers,
just as he was once against version control ... and Codes of Conduct.

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

Well, one of the reasons may be that we need a debugger that supports 
newer DWARF.
At some time we started hacking our llvm to not use a recent dwarf 
versions(4?).

Pedro.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?acbffc5a-f17f-5077-f9f0-46b9640ba115>