From owner-freebsd-current@FreeBSD.ORG Fri Oct 31 05:11:08 2014 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F48D8A7; Fri, 31 Oct 2014 05:11:08 +0000 (UTC) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id B8A776BC; Fri, 31 Oct 2014 05:11:07 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-229-232.lns20.per1.internode.on.net [121.45.229.232]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id s9V4rF7J007887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 30 Oct 2014 21:53:18 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <545315B5.503@freebsd.org> Date: Fri, 31 Oct 2014 12:53:09 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Garance A Drosehn , Ed Maste Subject: Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel/ References: <54511A7E.1020307@multiplay.co.uk> <20141030062026.GC8852@funkthat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Oct 2014 05:11:08 -0000 On 10/31/14, 1:41 AM, Garance A Drosehn wrote: > On 30 Oct 2014, at 12:49, Ed Maste wrote: > >> On 30 October 2014 02:20, John-Mark Gurney wrote: >>> Oh, make sure that make install (or installkernel) properly handles >>> moving the debug data too... i.e. kernel to kernel.old... >> Yes, in the case that /boot/kernel is moved to /boot/kernel.old >> /usr/lib/debug/boot/kernel is moved to /usr/lib/debug/boot/kernel.old. > I definitely like the idea of moving the debug symbols out to /usr/lib/debug > > I'm another person who sometimes has multiple kernels sitting in /boot > (which is one reason I'd like the debug symbols elsewhere!). I may > shuffle those around by hand, and I'm sure I won't remember to shuffle > around information under /usr/lib/debug. I also do things like > cp -rp kernel kernel-PreBigChange > where I save away a copy of the kernel for possible fallback (at some > unknown future date), but I wouldn't need two copies of the debug info. > > When we build a kernel, could we tag it with some unique-ID (by putting > that ID in a plain-text file inside the kernel's directory), and then > that unique-ID could be used for finding the correct debug info under > /usr/lib/debug? This way we wouldn't need to move around any of the > debug info under /usr/lib/debug. And we could tell which sets of > debug info should be removed by comparing the existing sets of debug > info with the kernel-unique-ID's which still exist under /boot. I'd put the debug symbls somewhere with a unique name and than add a symlink from the installed directory.. (and an ID file) So /boot/kernel.old/symbols points to /usr/lib/debug/kernelsymbols.20141031,1250 when you move the directory back to /boot/kernel, it STILL points to the right place.. occasionally remove all directories in /usr/lib/debug/kernelsymbols.* that are not pointed to by a symlink in /boot/*/symbols. An option could make the symlink relative for chroot/jail/nfs issues.. > > If debug tools need to have the debug-info for the booted kernel to > be in a fixed location, then maybe the boot-up process could create > a symlink from some fixed pathname to the correct debug info for the > kernel which the system booted up on. >