Date: Thu, 30 Oct 2014 14:26:39 +0000 From: Steven Hartland <killing@multiplay.co.uk> To: Ed Maste <emaste@freebsd.org> Cc: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ Message-ID: <54524A9F.8000400@multiplay.co.uk> In-Reply-To: <CAPyFy2BxfU2SAgkf-Bd1D_ZsgFsDSx=K=WvCKaPWqZ-1pkTm=A@mail.gmail.com> References: <CAPyFy2APVUxpAztmWY-ux7gUZ7B8Qk65CLHV_fVYmxsazKgCPg@mail.gmail.com> <54511A7E.1020307@multiplay.co.uk> <CAPyFy2Bw9JH4w0iZ5hj2R1Ga9T4BZn_Z-8UBJ-jT6tmO%2Bi8VeA@mail.gmail.com> <20141030023224.GA42236@troutmask.apl.washington.edu> <5451A843.90805@multiplay.co.uk> <076D8745-53C6-4AFE-86D3-FF9B94F4EC76@emc.com> <54520177.5000008@multiplay.co.uk> <44A64906-CB05-4B52-A797-596D3A0DF897@emc.com> <EEFB6867-A317-4BEF-B219-D26ACDF9622E@lists.zabbadoz.net> <54523B57.1010802@multiplay.co.uk> <CAPyFy2BxfU2SAgkf-Bd1D_ZsgFsDSx=K=WvCKaPWqZ-1pkTm=A@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30/10/2014 14:15, Ed Maste wrote:
> On 30 October 2014 09:21, Steven Hartland <killing@multiplay.co.uk> wrote:
>> On 30/10/2014 12:10, Bjoern A. Zeeb wrote:
>>> (a) symbol files are for developers. Developers are clever people, often
>>> with custom systems, they know how to deal with them as they already do
>>> whatever they want anyway in 7 different ways.
>> Yes and no, generating useful information from a users panic issue is
>> something we really need to ensure is still possible. As where they aren't
>> the developer, they are the source of the information.
>>
>> So maybe some sort of post processing utility?
> We're also going to make debug data for userland (libraries and
> binaries) available. On my system there's about 360MB of kernel debug
> and 1.5GB of userland debug, and we definitely don't want to
> unconditionally install all of that. Thus we're going to have to
> provide the capability of installing debug data at install time or
> later anyway,
>
> We already have some limited post-processing involved in kernel crash
> handling - /etc/rc.d/savecore to pull the crash out of the swap/dump
> partition, and crashinfo to extract useful information using kgdb.
> There are many useful improvements we could make in kernel crash
> handling, including having the process support on-demand fetching of
> the kernel debug data.
Yer that's the process that was in my head, if debug symbols aren't
available when savecore runs we're going to need a way to update / rerun
when they are available, or even better give it the ability to do the
same job with remote symbols?
> Sounds like having a way to not install symbols to the root partition for
> *binary* installs is the real requirement?
> That is a requirement, yes.
>
> Moving the debug data to a separate partition also opens up some
> compelling use cases for large scale deployments, where multiple
> systems run the same release. The machines can run from their own
> install on disk, but have the infrequently-used debug data NFS mounted
> from a common location. The / and /boot partitions may be mounted
> read-only.
Sound like a good idea :)
>
>>> The entire cp -pR kernel kernel.good solution is nothing I’d expect a user
>>> to ever do. But I am aware that’s a “developer standard”. Maybe we just
>>> need to improve the situation for ourselves rather than pessimising 98% of
>>> users out there.
>> Indeed.
> ...
>> I think overall there's options to move forward, we just need to ensure its
>> not at the expense of usability for those that do have space.
> Setting DEBUGDIR= in /etc/src.conf will retain the current behaviour
> of installing the debug data beside the kernel and modules (and
> userland binaries and libraries). Does this adequately address your
> use case?
Yep that works :)
>
>>> Whether that is /boot/kernel/symbols/*
>>> or /usr/lib/***, I couldn’t care less
> Note that if they go in /boot/kernel/symbols/ then we have to teach
> GDB, LLDB, and other tools to look there; if they go in /usr/lib/debug
> they're found automatically by the debuggers.
>
> We may have to add standalone debug path support to other tools, but
> it's very little additional work.
One thing to check would be to ensure that /usr is mounted when savecore
runs.
Regards
Steve
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?54524A9F.8000400>