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.Received on Wed Oct 29 2014 - 16:52:18 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:53 UTC