svn commit: r317094 - head/share/mk

[Rodney W. Grimes]

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

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