From owner-freebsd-current@FreeBSD.ORG Thu Feb 12 04:29:02 2015 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 42FB38E0; Thu, 12 Feb 2015 04:29:01 +0000 (UTC) Date: Thu, 12 Feb 2015 04:28:57 +0000 From: Glen Barber To: Ian Lepore Subject: Re: HEADS-UP: Enabling WITH_DEBUG_FILES by default Message-ID: <20150212042857.GJ1302@hub.FreeBSD.org> References: <20150212023912.GG1302@hub.FreeBSD.org> <1423713360.80968.89.camel@freebsd.org> <20150212041158.GH1302@hub.FreeBSD.org> <1423714981.80968.100.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IJFRpmOek+ZRSQoz" Content-Disposition: inline In-Reply-To: <1423714981.80968.100.camel@freebsd.org> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Current , Ed Maste 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: Thu, 12 Feb 2015 04:29:02 -0000 --IJFRpmOek+ZRSQoz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Feb 11, 2015 at 09:23:01PM -0700, Ian Lepore wrote: > On Thu, 2015-02-12 at 04:11 +0000, Glen Barber wrote: > > On Wed, Feb 11, 2015 at 08:56:00PM -0700, Ian Lepore wrote: > > > On Wed, 2015-02-11 at 22:21 -0500, Ed Maste wrote: > > > > On 11 February 2015 at 21:39, Glen Barber wrote: > > > > > > > > > > Within the next 24 hours, I will merge the release-install-debug = branch > > > > > into head, which will enable building and installing stripped deb= ugging > > > > > files by default. > > > > > > > > > > In general, this should have no significant impact, but any fallo= ut will > > > > > be addressed as soon as possible after the merge. > > > > > > > > > > Those that do not want debugging files built/installed by default= should > > > > > add 'WITHOUT_DEBUG_FILES=3D1' to src.conf(5). This will also be = noted in > > > > > UPDATING. > > > >=20 > > > > Note that the debug files do consume a reasonably large amount of d= isk > > > > space in both the OBJDIR and in the installed location under > > > > /usr/lib/debug. Users with limited disk space will probably want to > > > > disable them. As an example, the installed debug data on my laptop= is > > > > about 2GB. > > >=20 > > > Seriously? 2GB is bigger than the entire filesystem on many ARM boar= ds > > > that do useful work. Not to mention how long it will take to write a= ll > > > that to an sdcard (it already takes a long time to installworld/kernel > > > to an sdcard and it's only 400MB). > > >=20 > > > Just what are these files, and what use will the average user make of > > > them? > > >=20 > > > What use will I make of them, that is going to justify that every one= of > > > my couple-dozen build sandboxes will now be 4gb larger (a copy in obj > > > and a copy in the nfs root that things install to)? > > >=20 > > > How much time will this add to a build? > > >=20 > > > Yeah yeah, I can update a couple dozen src.conf files to eliminate th= em, > > > and that's not the biggest hassle in the world (but it's also not > > > nothing). It seems like this is a heavy enough load that it needs to > > > justify its existance. > > >=20 > >=20 > > The major benefit is that all debugging data that we need to properly > > debug application crashes in the base system will be available > > out-of-box. > >=20 > > There is a trade-off here, in both directions. For arm, for example, > > the trade-off is that the default installed userland would grow, however > > when there is a PR regarding an application crash, the tools to diagnose > > the issue are there by default (we do not need to ask that the utility > > is rebuilt with debugging options enabled, and then recreate the crash). > >=20 > > I considered making this an opt-in thing for arm, but given the above > > rationale, thought it would be more beneficial for the opposite route. > > If you feel necessary, however, we can turn this off by default for now > > for arm. > >=20 > > Glen > >=20 >=20 > I can't imagine that anybody is going to be happy with an installed > system size increase from 520 to 2520 MB no matter how much it helps > debugging, especially considering the the typical installation media is > in the 2-8 GB range (with lots of 2 and 4 GB cards out there because > that's what vendors bundle with the boards). >=20 Absolutely understood. As mentioned in a recent reply (before seeing this email), I'll provide a closer estimate of what to expect soon. Again, if you want this turned off for arm, that's fine. I would, however, like to see it enabled by default across the board eventually (even for -RELEASE builds). Glen --IJFRpmOek+ZRSQoz Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJU3CwJAAoJEAMUWKVHj+KTGyIP/iFk2uDVNOSIYc7+hXCuZkUB Gff1jtODPV1P1oBi7rhR9EdlvXgzZnz1Fpa/qcHEJ7Vnm54XJ60VfQZRTgA9Lj/4 v965cViXXdhMQ+7HZ1uQlQoYBIvjiMViMipIG/1gnTLNwqItUEcwZIksVFYVQu1O /5QvxB6Fd8yW8z90sMgLEjYFcuyJyAhLRG+YE+nFlC3tVPs6dQEMZlqZHenBI+Bx nbgtZrUTbhODLFQNxNmfya/8znsMB5R3KQm0bCivInPjPpvBdFEV+Dc20MExhJ80 8XC9iFhuJKnRrN7Cr14sp7yRjTC5Cm2x03WLOxXYgBHoyNvHWM6xIykzW1YfJPxY TfNnBp6Y92yINFO0vX18laDGJy0qTaF5W8Cv0mLn5JQo3IfzXOsaBF5WUl/ukIVC s2FP0qiF5pdJ+MaZNHbWmbLR+ejWjh/FVIMi4mNO5+eXeYbnYUX+PsGpmNAziPmR 7r/d5KBhpi25jjezAbm/83Zphkns5KXbFxYaoHVy57GNxPKU+uXlcbuCEk/B49cs p0h/xL4K1pPD/OlJgqoxszmCP2oKU+4P4sIOup/4zgSnC9htxWauxvCsjEcNdcQ5 bH3z3j5t/5d3QC7Zn4g/5rlgvDk4Wpv52RWDpeB9jFdZ8RYBs72wFgXrLZzt3Uhc PqDOWhnA0frnLUOnLb7H =K4/I -----END PGP SIGNATURE----- --IJFRpmOek+ZRSQoz--