On 30/10/2014 14:15, Ed Maste wrote:
On 30 October 2014 09:21, Steven Hartland <kill...@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
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
