On Tue, 2015-09-22 at 10:23 -0400, Ed Maste wrote:
> I am preparing to move the standalone kernel debug data out of
> /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the
> approach
> used for userland debug data. This significantly reduces the boot
> partition size requirement, and is a s
On 29/10/2014 19:58, Mark Johnston wrote:
> A while ago I wrote some code for libproc to handle .gnu_debuglink and
> read stripped sections out of the standalone debug file.
Just in case, I have an ugly-ish local patch for that too:
https://github.com/avg-I/freebsd/compare/wip/libproc-support-debu
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
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
On Oct 30, 2014, at 7:15, Ed Maste wrote:
…
>>> 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 autom
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/deb
On 30/10/2014 14:40, Ed Maste wrote:
On 30 October 2014 10:26, Steven Hartland wrote:
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 t
On 30 October 2014 10:26, Steven Hartland wrote:
>
> 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
On 30/10/2014 14:15, Ed Maste wrote:
On 30 October 2014 09:21, Steven Hartland 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
On 30 October 2014 09:21, Steven Hartland 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 way
On 30/10/2014 12:10, Bjoern A. Zeeb wrote:
On 30 Oct 2014, at 09:47 , O'Connor, Daniel wrote:
On 30 Oct 2014, at 19:44, Steven Hartland wrote:
On 30/10/2014 08:24, O'Connor, Daniel wrote:
On 30 Oct 2014, at 13:23, Steven Hartland wrote:
Making things harder to manage vs saving a little b
On 30 October 2014 09:07, Ed Maste wrote:
> On 29 October 2014 22:32, Steve Kargl
> wrote:
>> On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote:
>>> On 29 October 2014 12:49, Steven Hartland wrote:
>>> > Hmm not sure I like this idea as it would make it more difficult to make a
>>> > cop
On 29 October 2014 22:32, Steve Kargl wrote:
> On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote:
>> On 29 October 2014 12:49, Steven Hartland wrote:
>> > Hmm not sure I like this idea as it would make it more difficult to make a
>> > copy / backup a kernel.
>> >
>> > ATM when I want to co
On 30 Oct 2014, at 09:47 , O'Connor, Daniel wrote:
> On 30 Oct 2014, at 19:44, Steven Hartland wrote:
>> On 30/10/2014 08:24, O'Connor, Daniel wrote:
>>> On 30 Oct 2014, at 13:23, Steven Hartland wrote:
Making things harder to manage vs saving a little bit of space on the
root partiti
On 30 Oct 2014, at 13:23, Steven Hartland wrote:
> Making things harder to manage vs saving a little bit of space on the
> root partition really doesn't sound like a good idea; especially when
> with the ZFS install, which I would suggest is becoming the norm, the
> root partition doesn't suff
On 30 Oct 2014, at 19:44, Steven Hartland wrote:
> On 30/10/2014 08:24, O'Connor, Daniel wrote:
>> On 30 Oct 2014, at 13:23, Steven Hartland wrote:
>>> Making things harder to manage vs saving a little bit of space on the
>>> root partition really doesn't sound like a good idea; especially when
On 30/10/2014 09:47, O'Connor, Daniel wrote:
On 30 Oct 2014, at 19:44, Steven Hartland wrote:
On 30/10/2014 08:24, O'Connor, Daniel wrote:
On 30 Oct 2014, at 13:23, Steven Hartland wrote:
Making things harder to manage vs saving a little bit of space on the
root partition really doesn't sou
On 30/10/2014 08:24, O'Connor, Daniel wrote:
On 30 Oct 2014, at 13:23, Steven Hartland wrote:
Making things harder to manage vs saving a little bit of space on the
root partition really doesn't sound like a good idea; especially when
with the ZFS install, which I would suggest is becoming the
Steven Hartland wrote this message on Wed, Oct 29, 2014 at 16:49 +:
> Hmm not sure I like this idea as it would make it more difficult to make
> a copy / backup a kernel.
>
> ATM when I want to copy a kernel for debugging its a one liner,
> splitting debug symbols off to /usr/lib would preve
On 10/30/14, 10:32 AM, Steve Kargl wrote:
On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote:
On 29 October 2014 12:49, Steven Hartland wrote:
Hmm not sure I like this idea as it would make it more difficult to make a
copy / backup a kernel.
ATM when I want to copy a kernel for debuggin
On 30/10/2014 02:32, Steve Kargl wrote:
On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote:
On 29 October 2014 12:49, Steven Hartland wrote:
Hmm not sure I like this idea as it would make it more difficult to make a
copy / backup a kernel.
ATM when I want to copy a kernel for debugging
On Wed, Oct 29, 2014 at 03:15:50PM -0400, Ed Maste wrote:
> On 29 October 2014 12:49, Steven Hartland wrote:
> > Hmm not sure I like this idea as it would make it more difficult to make a
> > copy / backup a kernel.
> >
> > ATM when I want to copy a kernel for debugging its a one liner, splitting
On 29 October 2014 12:49, Steven Hartland wrote:
> Hmm not sure I like this idea as it would make it more difficult to make a
> copy / backup a kernel.
>
> ATM when I want to copy a kernel for debugging its a one liner, splitting
> debug symbols off to /usr/lib would prevent this.
To retain the c
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 wrote:
> >> On 29 Oct 2014, at 03:11, Ed Maste wrote:
> >>
> >>> /usr/lib/debug is the standard location for standalone debug data
> >>> established by
Hmm not sure I like this idea as it would make it more difficult to make
a copy / backup a kernel.
ATM when I want to copy a kernel for debugging its a one liner,
splitting debug symbols off to /usr/lib would prevent this.
Is there not a way to allow separate install of the debug files but to
On 29/10/2014 10:17, Ed Maste wrote:
> On 29 October 2014 05:05, David Chisnall wrote:
>> On 29 Oct 2014, at 03:11, Ed Maste 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 updat
On Wed, Oct 29, 2014 at 10:17:33AM -0400, Ed Maste wrote:
> On 29 October 2014 05:05, David Chisnall wrote:
> > On 29 Oct 2014, at 03:11, Ed Maste wrote:
> >
> >> /usr/lib/debug is the standard location for standalone debug data
> >> established by GDB, and seems like a decent enough location. I'
On 29 October 2014 05:05, David Chisnall wrote:
> On 29 Oct 2014, at 03:11, Ed Maste 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 loo
On 29 Oct 2014, at 03:11, Ed Maste 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
On 28 October 2014 23:04, Kevin Oberman wrote:
>
> Finally! This is great news.
>
> /usr/lib seems like an odd place, though. Does not seem to match the
> description in hier(7) (not that the man page can't be updated). Looks to me
> like it fits /var a bit better, though I'm not sure that much da
On Tue, Oct 28, 2014 at 5:20 PM, Ed Maste wrote:
> I am preparing to move the standalone kernel debug data out of
> /boot/kernel/ into /usr/lib/debug/boot/kernel/, mirroring the approach
> used for userland debug data. This significantly reduces the boot
> partition size requirement, and is a ste
31 matches
Mail list logo
