Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/

On 30 October 2014 09:21, Steven Hartland <killing_at_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.

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

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

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