svn commit: r317094 - head/share/mk

[Eric van Gyzen]

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

Eric