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

Mark Johnston markjdb at gmail.com
Wed Oct 29 17:52:18 UTC 2014

On Wed, Oct 29, 2014 at 12:10:44PM -0400, Andriy Gapon wrote:
> On 29/10/2014 10:17, Ed Maste wrote:
> > On 29 October 2014 05:05, David Chisnall <theraven at freebsd.org> wrote:
> >> On 29 Oct 2014, at 03:11, Ed Maste <emaste at freebsd.org> wrote:
> >>
> >>> /usr/lib/debug is the standard location for standalone debug data
> >>> established by GDB, and seems like a decent enough location. I'll make
> >>> sure to update the man page.
> >>
> >> Do gdb and lldb also look in /usr/local/lib/debug?  If not, it would be great if we could at least teach lldb to do this so that we can start thinking about splitting debug info into separate packages for ports (and providing it as an optional install for everything).
> > 
> > Not yet, but it's trivial to add for at least LLDB. My end goal is
> > what you describe - kernel, base system userland, and packages/ports
> > can all provide standalone debug packages which will install to a
> > consistent and well-known location, and be picked up automatically by
> > the debugger.
> > 
> > Part of this project depends on moving past our old binutils though,
> > so we can start using the build-id ELF note to link the executable or
> > library with its associated debug data.
> Another part of the issue is DTrace tools that need to look for userland
> symbols.

A while ago I wrote some code for libproc to handle .gnu_debuglink and
read stripped sections out of the standalone debug file. It seemed to me
though that that kind of functionality really belongs somewhere more
central, maybe in libelf. I'm not really sure what the interface should
look like; I haven't seen any other libraries that handle external debug
files, aside from bfd.

Also note that DTrace doesn't strictly need userland symbols to work.
The pid provider is a lot more useful if they're available though.

More information about the freebsd-current mailing list