Re: HEADS UP: Standalone kernel debug files moving out of /boot/kernel (really, this time)

[Rui Paulo]

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 step towards supporting the
> installation of kernel debug data ony when required. LLDB and GDB
> automatically search for debug data under /usr/lib/debug/ so this
> change should be transparent from an end-user perspective.
> 
> The change can be reviewed in Phabricator at
> https://reviews.freebsd.org/D1006 and can be fetched as a unified
> diff
> from https://people.freebsd.org/~emaste/patches/D1006.diff
> 
> This change was discussed on -current last year[1] and a number of
> concerns were raised. These are addressed in the updated patch, and
> I'll summarize them here:
> 
> * /usr/lib seems like an odd location for this data
> /usr/lib/debug is the standard location established by GDB, and seems
> reasonable enough. I don't want to introduce gratuitous differences
> when compared with other systems.
> 
> * Do gdb / lldb look also in /usr/local/lib/debug, for ports debug
> files?
> Not yet; this is definitely something to address with additional
> work.
> 
> * Is it possible to keep the current behaviour?
> Yes, set KERN_DEBUGDIR="" in src.conf(5).
> 
> * /usr now needs to be mounted for savecore to work
> Savecore does not rely on debug files; crashinfo does. As crashinfo
> also requires /usr/bin/gdb /usr already needs to be mounted.
> 
> * This makes working with multiple kernels more difficult.
> Users with a workflow requiring a single "cp" or "mv" to shuffle
> around kernels and debug data can use the src.conf(5) setting to keep
> things as today. The techniques documented in build(7) for working
> with multiple named kernels require no changes; for example a kernel
> in /boot/newkernel/ will have its debug data in
> /usr/lib/debug/boot/newkernel/. The kernel to kernel.old rotation
> also
> works on both /boot/kernel and /usr/lib/debug/boot/kernel.
> 
> * Why rename .symbols to .debug?
> 1) This is what they're called elsewhere.
> 2) It's not an accurate description of the file's content. Some
> symbol
> data also exists in the binary or library, and there is a lot more
> debugging information in the standalone debug file than just symbols.
> 3) Userland and kernel debug data will have the same debug extension.
> Renaming them along with the other changes is a better approach than
> having another change later on.
> 
> I plan to commit the change later this week.
> 

Yay, thanks!


-- 
Rui Paulo

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

HEADS UP: Standalone kernel debug files moving out of /boot/kernel (really, this time)

[Ed Maste]

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 step towards supporting the
installation of kernel debug data ony when required. LLDB and GDB
automatically search for debug data under /usr/lib/debug/ so this
change should be transparent from an end-user perspective.

The change can be reviewed in Phabricator at
https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
from https://people.freebsd.org/~emaste/patches/D1006.diff

This change was discussed on -current last year[1] and a number of
concerns were raised. These are addressed in the updated patch, and
I'll summarize them here:

* /usr/lib seems like an odd location for this data
/usr/lib/debug is the standard location established by GDB, and seems
reasonable enough. I don't want to introduce gratuitous differences
when compared with other systems.

* Do gdb / lldb look also in /usr/local/lib/debug, for ports debug files?
Not yet; this is definitely something to address with additional work.

* Is it possible to keep the current behaviour?
Yes, set KERN_DEBUGDIR="" in src.conf(5).

* /usr now needs to be mounted for savecore to work
Savecore does not rely on debug files; crashinfo does. As crashinfo
also requires /usr/bin/gdb /usr already needs to be mounted.

* This makes working with multiple kernels more difficult.
Users with a workflow requiring a single "cp" or "mv" to shuffle
around kernels and debug data can use the src.conf(5) setting to keep
things as today. The techniques documented in build(7) for working
with multiple named kernels require no changes; for example a kernel
in /boot/newkernel/ will have its debug data in
/usr/lib/debug/boot/newkernel/. The kernel to kernel.old rotation also
works on both /boot/kernel and /usr/lib/debug/boot/kernel.

* Why rename .symbols to .debug?
1) This is what they're called elsewhere.
2) It's not an accurate description of the file's content. Some symbol
data also exists in the binary or library, and there is a lot more
debugging information in the standalone debug file than just symbols.
3) Userland and kernel debug data will have the same debug extension.
Renaming them along with the other changes is a better approach than
having another change later on.

I plan to commit the change later this week.

[1] https://lists.freebsd.org/pipermail/freebsd-current/2014-October/052926.html
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

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

[Andriy Gapon]

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-debug-files

> 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.

Some thoughts on all of the above.

-- 
Andriy Gapon
___
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"

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

[Julian Elischer]

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.



___
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"

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

[Garance A Drosehn]

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.

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.

-- 
Garance Alistair Drosehn= dro...@rpi.edu
Senior Systems Programmer   or   g...@freebsd.org
Rensselaer Polytechnic Institute; Troy, NY;  USA
___
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"

Booting from symlinked kernels (was "HEADS UP: Standalone kernel debug files moving out of /boot/kernel/")

[Garrett Cooper]

On Oct 30, 2014, at 6: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
 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 current behaviour you can set DEBUGDIR= (i.e., empty),
>>> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.
>> 
>> No, you can't.
>> 
>> su root
>> cp -pR /boot/kernel /boot/good
>> 
>> Where does DEBUGDIR enter the picture?
> 
> In your kernel build configuration (src.conf or similar ways).

If you use the kernel build infrastructure properly, the debug info should be 
installed to ${DEBUGDIR}/boot/${INSTKERNNAME} — not ${DEBUGDIR}/boot/kernel 
(the latter is broken for folks like my that have multiple kernel configs in 
their src.conf).

As far as the symlink trick for /boot/kernel is concerned, that only works on 
UFS. I used to use it on ZFS, it broke one day, I sent out an email and got 
some replies back stating that they weren’t really worried about the feature 
being broken (I can hunt down the email thread… I just don’t have it in my 
search results right now). Another worthwhile bug to explore/fix is: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=153996 .

Cheers!
-Garrett


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Garrett Cooper]

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 automatically by the debuggers.
> 
> We may have to add standalone debug path support to other tools, but
> it's very little additional work.

Teaching gdb/lldb/etc to look in ${DEBUGDIR} for each element in `kenv 
module_path` would be really nice. It won’t fix debug info with all kids 
(open-vm-tools or virtualbox installs to /usr/local IIRC), but it’s better than 
nothing.
Thanks!


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Ed Maste]

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.
___
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"

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

[Steven Hartland]

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 the same
job with remote symbols?

Yeah, remote symbol support will be excellent (eventually).

Crashinfo already operates on the most recent dump by default, so the
solution could be as simple as adding a flag to fetch debug files if
not already installed. The user would only need to run crashinfo -f to
regenerate the crash information with debug data available (and we
could mention that explicitly in the crash report).


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 :)

Great.

I've been pondering this for so long that I may have forgotten not
everyone has the same context.


One thing to check would be to ensure that /usr is mounted when savecore
runs.

Indeed, but we're covered there: the crash info is generated by
/usr/sbin/crashinfo, which relies on /usr/bin/gdb, so it better be
mounted :)
Fantastic, thanks for taking the time to address my concerns, much 
appreciated :D

___
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"

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

[Ed Maste]

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?

Yeah, remote symbol support will be excellent (eventually).

Crashinfo already operates on the most recent dump by default, so the
solution could be as simple as adding a flag to fetch debug files if
not already installed. The user would only need to run crashinfo -f to
regenerate the crash information with debug data available (and we
could mention that explicitly in the crash report).

>> 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 :)

Great.

I've been pondering this for so long that I may have forgotten not
everyone has the same context.

> One thing to check would be to ensure that /usr is mounted when savecore
> runs.

Indeed, but we're covered there: the crash info is generated by
/usr/sbin/crashinfo, which relies on /usr/bin/gdb, so it better be
mounted :)
___
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"

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

[Steven Hartland]

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 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"

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

[Ed Maste]

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 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.

> 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.

>> 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?

>> 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.
___
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"

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

[Steven Hartland]

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 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 suffer from space issues anyway.

Note that it’s not “a little bit” of space.
[freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}'
49312
[freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
212464

i.e. the debug information is more than 4x larger than the code its for (!).

That's still a trivial about of space in the grand scheme of things.

Yes.

No it is not a trivial amount of space;  it’s about 20ish% of the installation 
of the base system.
It may be a decent percentage but when that's a percentage of a small 
number its still results in a trivial amount of space in the grand 
scheme of things, which was my point ;-)

I guess I am one source for the request to get them out of 
/boot/kernel/*.symbols into a spearate tarball and not install them by default 
for users.
The thing to keep in mind, if we don't have symbols installed is how we 
create useful panic information.

The reasons for me are indeed manyfold:

(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?

(b) A user should usually never have to bother with them, so why have them 
installed in first place?  They go onto (release) the media so that developers 
have access to them, or that users, if guided by a developer, can install them 
to debug a problem.  Moving them to a separate directory and into a different 
tarball makes that a lot easier.

Assuming the above is solved yes.

(c) We have people deploying gazillions of FreeBSD systems from default media, 
this stuff does add up;  10TB sounds small unless you have to back it up 
regularly, need disaster copies, or you need to minimise recovery or migration 
time, when every s is worth a few $$s.
Are you suggesting you only backup your root partition and not your usr 
partition, as if so its a null argument as the total size is still the same.


I'm assuming not and your saying we shouldn't install debug at all, 
which has the above side effect.

(d) A couple of times a year I do spare VM image backup and recovery including 
migration.  Moving the data back and forth can only happen in a very limited 
time frame, so I try to keep these VM images as small as possible.  rm -f 
/boot/kernel/*.symbol after install is really not keeping the sparseness as no 
one really supports TRIM on the VM images. Thus I’d just have lost 200MB * n 
VMs that I need to move around over 200ms RTT.  There are cruel workarounds; I 
know how to apply them as I am a developer, but if I do this stuff, there must 
be 1000s of users doing that, and they don’t.
Sounds like having a way to not install symbols to the root partition 
for *binary* installs is the real requirement?


So having an alternative location off root would be solution.

(e) People still have / (boot) filesystems in the 256M-1G space for the 
foreseeable future.  How do you ever cramp two kernels in there during an 
update for a machine that you will never ever see again because it’s in 
Antarctica on a 9600 baud connection?
While I appreciate such systems exist surely given your previous point 
where you actually don't want them installed at all, so providing that 
option instead of moving them to a different location can causing a load 
more issues is a better solution is it not?

(f) …

Yes I can understand that on these 40TB ZFS machines, no one gives a damn about 
200MB, but unfortunately not the entire world runs on these kinds of machines.  
 We have plenty of users on 10 year old hardware still running a FreeBSD 
installation and it works perfectly fine and does the job (until the HW dies;-).


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 personally do not mind where the symbol files will end up as long as they are 
in their own directory and not onto systems by default with releases unless 
someone ticks a box.  Whether that is /boot/kernel/symbols/* or /usr/lib/***, I 
couldn’t care less, apart from the fact that /boot remain

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

[Ed Maste]

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
>>> > 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 current behaviour you can set DEBUGDIR= (i.e., empty),
>>> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.
>>
>> No, you can't.
>>
>> su root
>> cp -pR /boot/kernel /boot/good
>>
>> Where does DEBUGDIR enter the picture?
>
> In your kernel build configuration (src.conf or similar ways).

Oops, that should be "build / install configuration (src.conf or
similar)."  That is, if you set DEBUGDIR= then the debug data will be
installed in the same directory as the kernel / binaries / libraries,
and everything will work as it does today.
___
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"

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

[Ed Maste]

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 copy a kernel for debugging its a one liner, splitting
>> > debug symbols off to /usr/lib would prevent this.
>>
>> To retain the current behaviour you can set DEBUGDIR= (i.e., empty),
>> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.
>
> No, you can't.
>
> su root
> cp -pR /boot/kernel /boot/good
>
> Where does DEBUGDIR enter the picture?

In your kernel build configuration (src.conf or similar ways).
___
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"

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

[Bjoern A. Zeeb]

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 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 suffer from space issues anyway.
>>> Note that it’s not “a little bit” of space.
>>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print 
>>> $5}'
>>> 49312
>>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
>>> 212464
>>> 
>>> i.e. the debug information is more than 4x larger than the code its for (!).
>> That's still a trivial about of space in the grand scheme of things.
> 
> Yes.

No it is not a trivial amount of space;  it’s about 20ish% of the installation 
of the base system.


I guess I am one source for the request to get them out of 
/boot/kernel/*.symbols into a spearate tarball and not install them by default 
for users.


The reasons for me are indeed manyfold:

(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.

(b) A user should usually never have to bother with them, so why have them 
installed in first place?  They go onto (release) the media so that developers 
have access to them, or that users, if guided by a developer, can install them 
to debug a problem.  Moving them to a separate directory and into a different 
tarball makes that a lot easier.

(c) We have people deploying gazillions of FreeBSD systems from default media, 
this stuff does add up;  10TB sounds small unless you have to back it up 
regularly, need disaster copies, or you need to minimise recovery or migration 
time, when every s is worth a few $$s.

(d) A couple of times a year I do spare VM image backup and recovery including 
migration.  Moving the data back and forth can only happen in a very limited 
time frame, so I try to keep these VM images as small as possible.  rm -f 
/boot/kernel/*.symbol after install is really not keeping the sparseness as no 
one really supports TRIM on the VM images. Thus I’d just have lost 200MB * n 
VMs that I need to move around over 200ms RTT.  There are cruel workarounds; I 
know how to apply them as I am a developer, but if I do this stuff, there must 
be 1000s of users doing that, and they don’t.

(e) People still have / (boot) filesystems in the 256M-1G space for the 
foreseeable future.  How do you ever cramp two kernels in there during an 
update for a machine that you will never ever see again because it’s in 
Antarctica on a 9600 baud connection?

(f) …

Yes I can understand that on these 40TB ZFS machines, no one gives a damn about 
200MB, but unfortunately not the entire world runs on these kinds of machines.  
 We have plenty of users on 10 year old hardware still running a FreeBSD 
installation and it works perfectly fine and does the job (until the HW dies;-).


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.


I personally do not mind where the symbol files will end up as long as they are 
in their own directory and not onto systems by default with releases unless 
someone ticks a box.  Whether that is /boot/kernel/symbols/* or /usr/lib/***, I 
couldn’t care less, apart from the fact that /boot remains on a space 
constrained file system for a lot of legacy system that symbol files have 
filled up more than once for me in the past.


So maybe the real solution is indeed for developers to think how to manage 
kernels and related files and settings in the future?

— 
Bjoern A. Zeeb "Come on. Learn, goddamn it.", WarGames, 1983

___
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"

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

[O'Connor, Daniel]

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 suffer from space issues anyway.

Note that it’s not “a little bit” of space.
[freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}'
49312
[freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
212464

i.e. the debug information is more than 4x larger than the code its for (!).

I agree managing the symbol files does become significantly more difficult in 
this case but the patch makes quite a substantial difference to the number of 
kernels you can keep in / (especially on older installs which have <1GB roots).

Perhaps there could be a flag to disable it just for the kernel that could be 
put into /etc/make.conf? That way it’s set and forget if you are kernel 
juggling.

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



___
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"

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

[O'Connor, Daniel]

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
>>> with the ZFS install, which I would suggest is becoming the norm, the
>>> root partition doesn't suffer from space issues anyway.
>> Note that it’s not “a little bit” of space.
>> [freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}'
>> 49312
>> [freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
>> 212464
>> 
>> i.e. the debug information is more than 4x larger than the code its for (!).
> That's still a trivial about of space in the grand scheme of things.

Yes.

>> I agree managing the symbol files does become significantly more difficult 
>> in this case but the patch makes quite a substantial difference to the 
>> number of kernels you can keep in / (especially on older installs which have 
>> <1GB roots).
> The better solution is to not use a 1GB root.

Unfortunately once you install it’s impossible to expand. There are quite a few 
older systems that have been upgraded with relatively small root partitions.

>> Perhaps there could be a flag to disable it just for the kernel that could 
>> be put into /etc/make.conf? That way it’s set and forget if you are kernel 
>> juggling.
> Making it a none default option which can be used by those who have got 
> limited space on their root.

Perhaps, but the defaults have been for quite small root partitions for a long 
time so I expect there are a lot of systems with a small root.

Regards,
Daniel O’Connor

Senior Software Engineer
Isilon Platforms Team



___
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"

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

[Steven Hartland]

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 sound like a good idea; especially when
with the ZFS install, which I would suggest is becoming the norm, the
root partition doesn't suffer from space issues anyway.

Note that it’s not “a little bit” of space.
[freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}'
49312
[freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
212464

i.e. the debug information is more than 4x larger than the code its for (!).

That's still a trivial about of space in the grand scheme of things.

Yes.


I agree managing the symbol files does become significantly more difficult in this 
case but the patch makes quite a substantial difference to the number of kernels 
you can keep in / (especially on older installs which have <1GB roots).

The better solution is to not use a 1GB root.

Unfortunately once you install it’s impossible to expand. There are quite a few 
older systems that have been upgraded with relatively small root partitions.
I would suggest we treat those as legacy systems and look to improve the 
layout moving forward, instead of applying changes which make it more 
difficult to maintain for everyone.

Perhaps there could be a flag to disable it just for the kernel that could be 
put into /etc/make.conf? That way it’s set and forget if you are kernel 
juggling.

Making it a none default option which can be used by those who have got
limited space on their root.

Perhaps, but the defaults have been for quite small root partitions for a long 
time so I expect there are a lot of systems with a small root.
These systems are working fine though are they not? They may not be able 
to have loads of kernels installed but if you want to do that then its 
worth the pain of the reinstall instead of penalizing everyone.


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"

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

[Steven Hartland]

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 norm, the
root partition doesn't suffer from space issues anyway.

Note that it’s not “a little bit” of space.
[freebsd10 8:21] /boot/kernel >ll kernel *.ko| awk '{i += $5} END {print $5}'
49312
[freebsd10 8:21] /boot/kernel >ll *.symbols | awk '{i += $5} END {print $5}’
212464

i.e. the debug information is more than 4x larger than the code its for (!).

That's still a trivial about of space in the grand scheme of things.

I agree managing the symbol files does become significantly more difficult in this 
case but the patch makes quite a substantial difference to the number of kernels 
you can keep in / (especially on older installs which have <1GB roots).

The better solution is to not use a 1GB root.

Perhaps there could be a flag to disable it just for the kernel that could be 
put into /etc/make.conf? That way it’s set and forget if you are kernel 
juggling.
Making it a none default option which can be used by those who have got 
limited space on their root.


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"

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

[John-Mark Gurney]

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 prevent this.
> 
> Is there not a way to allow separate install of the debug files but to 
> the same location maintaining compartmentalization for the needed kernel 
> files?

Oh, make sure that make install (or installkernel) properly handles
moving the debug data too... i.e. kernel to kernel.old...

> On 29/10/2014 00:20, 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 step towards supporting the
> >installation of kernel debug data ony when required. LLDB and GDB
> >automatically search for debug data under /usr/lib/debug/ so this
> >change should be transparent from an end-user perspective.
> >
> >The change can be reviewed in Phabricator at
> >https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
> >from https://people.freebsd.org/~emaste/patches/D1006.diff
> >
> >This does not change any defaults or knobs: kernel debug files are
> >still built by default, and may be disabled by setting
> >WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize
> >this with userland debug in a later step.
> >
> >Note that the change renames the intermediate and debug data files to
> >be consistent with userland debug data: in the build directory the
> >kernel with debug data included is now named kernel.full, and and
> >kernel.debug is the standalone debug data file.
> >
> >I plan to merge this in a few days if there are no issues reported in
> >further review or testing.

-- 
  John-Mark Gurney  Voice: +1 415 225 5579

 "All that I will do, has been done, All that I have, has not."
___
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"

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

[Julian Elischer]

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 debugging its a one liner, splitting
debug symbols off to /usr/lib would prevent this.

To retain the current behaviour you can set DEBUGDIR= (i.e., empty),
as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.

No, you can't.

su root
cp -pR /boot/kernel /boot/good

Where does DEBUGDIR enter the picture?  The above will copy
both kernel and kernel.symbol to /boot/good.  With your scheme
one loses kernel.symbol (along with all other *.symbol files?).
If one escapes to the boot prompt, she can do 'boot /boot/good/kernel',
will the boot process automatically find a (nonexistant?)
/usr/lib/boot/good/kernel.symbol.
you can also set "KERNEL" in the make and it will install to 
/boot/$KERNEL/


It would need to put the symbols in /usr/lib/...$KERNEL/ as well, and  
then you are bound to get confusion when you copy the new kernel to 
the default place when you tested it.  maybe put a symlink in the 
kernel directory and follow that? keeping symbols and kernel in sync 
is going to get a lot more complicated.







___
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"

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

[Steven Hartland]

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 its a one liner, splitting
debug symbols off to /usr/lib would prevent this.

To retain the current behaviour you can set DEBUGDIR= (i.e., empty),
as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.

No, you can't.

su root
cp -pR /boot/kernel /boot/good

Where does DEBUGDIR enter the picture?  The above will copy
both kernel and kernel.symbol to /boot/good.  With your scheme
one loses kernel.symbol (along with all other *.symbol files?).
If one escapes to the boot prompt, she can do 'boot /boot/good/kernel',
will the boot process automatically find a (nonexistant?)
/usr/lib/boot/good/kernel.symbol.
Indeed, if my understanding of this proposal is correct it will make 
working with multiple kernels much harder.


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 suffer from space issues anyway.

___
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"

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

[Steve Kargl]

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
> > debug symbols off to /usr/lib would prevent this.
> 
> To retain the current behaviour you can set DEBUGDIR= (i.e., empty),
> as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.

No, you can't.

su root
cp -pR /boot/kernel /boot/good

Where does DEBUGDIR enter the picture?  The above will copy
both kernel and kernel.symbol to /boot/good.  With your scheme
one loses kernel.symbol (along with all other *.symbol files?).
If one escapes to the boot prompt, she can do 'boot /boot/good/kernel',
will the boot process automatically find a (nonexistant?)
/usr/lib/boot/good/kernel.symbol.

-- 
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"

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

[Ed Maste]

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 current behaviour you can set DEBUGDIR= (i.e., empty),
as the debug file install path is ${DESTDIR}${DEBUGDIR}${KODIR}.
___
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"

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

[Mark Johnston]

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 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.
___
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"

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

[Steven Hartland]

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 
the same location maintaining compartmentalization for the needed kernel 
files?


On 29/10/2014 00:20, 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 step towards supporting the
installation of kernel debug data ony when required. LLDB and GDB
automatically search for debug data under /usr/lib/debug/ so this
change should be transparent from an end-user perspective.

The change can be reviewed in Phabricator at
https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
from https://people.freebsd.org/~emaste/patches/D1006.diff

This does not change any defaults or knobs: kernel debug files are
still built by default, and may be disabled by setting
WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize
this with userland debug in a later step.

Note that the change renames the intermediate and debug data files to
be consistent with userland debug data: in the build directory the
kernel with debug data included is now named kernel.full, and and
kernel.debug is the standalone debug data file.

I plan to merge this in a few days if there are no issues reported in
further review or testing.

-Ed
___
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"


___
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"

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

[Andriy Gapon]

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 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.

-- 
Andriy Gapon
___
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"

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

[Baptiste Daroussin]

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'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.

Port debuginfo packages are coming sooner than later so yeah lldb reading a
default standard location in localbase would be nice :)

regards,
Bapt


pgpD6rNWFpTNl.pgp
Description: PGP signature

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

[Ed Maste]

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 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.
___
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"

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

[David Chisnall]

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 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).

David

___
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"

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

[Ed Maste]

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 data is
> appropriate for many /var partitions.

/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.

-Ed
___
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"

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

[Kevin Oberman]

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 step towards supporting the
> installation of kernel debug data ony when required. LLDB and GDB
> automatically search for debug data under /usr/lib/debug/ so this
> change should be transparent from an end-user perspective.
>
> The change can be reviewed in Phabricator at
> https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
> from https://people.freebsd.org/~emaste/patches/D1006.diff
>
> This does not change any defaults or knobs: kernel debug files are
> still built by default, and may be disabled by setting
> WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize
> this with userland debug in a later step.
>
> Note that the change renames the intermediate and debug data files to
> be consistent with userland debug data: in the build directory the
> kernel with debug data included is now named kernel.full, and and
> kernel.debug is the standalone debug data file.
>
> I plan to merge this in a few days if there are no issues reported in
> further review or testing.
>
> -Ed
>

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 data is
appropriate for many /var partitions.

Still, wherever the symbol files end up, getting them out of root is
something many people have wanted for a long time.
--
R. Kevin Oberman, Network Engineer, Retired
E-mail: rkober...@gmail.com
___
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"

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

[Ed Maste]

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 step towards supporting the
installation of kernel debug data ony when required. LLDB and GDB
automatically search for debug data under /usr/lib/debug/ so this
change should be transparent from an end-user perspective.

The change can be reviewed in Phabricator at
https://reviews.freebsd.org/D1006 and can be fetched as a unified diff
from https://people.freebsd.org/~emaste/patches/D1006.diff

This does not change any defaults or knobs: kernel debug files are
still built by default, and may be disabled by setting
WITHOUT_KERNEL_SYMBOLS=YES in /etc/src.conf. I hope to rationalize
this with userland debug in a later step.

Note that the change renames the intermediate and debug data files to
be consistent with userland debug data: in the build directory the
kernel with debug data included is now named kernel.full, and and
kernel.debug is the standalone debug data file.

I plan to merge this in a few days if there are no issues reported in
further review or testing.

-Ed
___
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"