Re: [gentoo-dev] Defaulting for debug information in profiles
On 17 December 2012 18:55, Tomáš Chvátal tomas.chva...@gmail.com wrote: 2012/12/17 Ben de Groot yng...@gentoo.org: Please don't. For most users this is a waste of resources. On first look it seems like waste of resources. On second hand it makes stuff easy wrt bugreports provided by users. And believe me when I say most upstreams are pissed by gentoo reports because they lack any good debuginfo features, nor they know how to tell users how to make their systems contain debug informations. I have seen quite few upstreams rejecting all by Gentoo reported issues because of this, plus they were quite suprised that I actually can generate any sane debug informations with it. I still think it is a bad idea to enable something that is not necessary for most users by default. For your purposes it should be enough to update our existing documentation about debugging, and link to it from the handbook. Let the user make an informed choice by himself. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Montag, 17. Dezember 2012, 11:48:12 schrieb Walter Dnes:
On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
1) --- kde-base/kate
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Result: No size change at all.
2) --- dev-libs/lzo
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558664
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558304
Result: A difference of 260 bytes or 0.06%. Far away from the assumed
300%.
Conclusion:
I do not doubt that -ggdb adds size. It does. And maybe, if I did an
emerge -e @world would reduce the size used on my system between 30% and
40%. But not about 66% like assumed.
However, even if it where around 5-6 G, it would be thrice the initial
assumption of 2G. And that's the whole point.
On my 32-bit machines I have...
FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables CXXFLAGS=${CFLAGS}
See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables. Would I
have to rebuild system and world without...
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
...to have debug data available?
No, you haven't, if you have compiled everything with -g or -ggdb.
According to the web page you linked, the DWARF-2 tables are then written into
the .debug files. Without -g/-ggdb, they are stripped and no longer available
for debugging.
So according to your CFLAGS, you'd have to rebuild everything, yes, but a
simple -g would do.
Oh, and splitdebug in FEATURES would be a good idea, too! ;)
Sincerly
Sven
--
http://pwxlib.sourceforge.net
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
W dniu 18.12.2012 12:13, Sven Eden pisze:
Am Montag, 17. Dezember 2012, 11:48:12 schrieb Walter Dnes:
On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
1) --- kde-base/kate
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Result: No size change at all.
2) --- dev-libs/lzo
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558664
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558304
Result: A difference of 260 bytes or 0.06%. Far away from the assumed
300%.
Conclusion:
I do not doubt that -ggdb adds size. It does. And maybe, if I did an
emerge -e @world would reduce the size used on my system between 30% and
40%. But not about 66% like assumed.
However, even if it where around 5-6 G, it would be thrice the initial
assumption of 2G. And that's the whole point.
On my 32-bit machines I have...
FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables CXXFLAGS=${CFLAGS}
See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables. Would I
have to rebuild system and world without...
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
...to have debug data available?
No, you haven't, if you have compiled everything with -g or -ggdb.
According to the web page you linked, the DWARF-2 tables are then written
into
the .debug files. Without -g/-ggdb, they are stripped and no longer available
for debugging.
So according to your CFLAGS, you'd have to rebuild everything, yes, but a
simple -g would do.
Oh, and splitdebug in FEATURES would be a good idea, too! ;)
Hi Sven!
Meseems you are not right, please look at it:
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep unwind\|-g
[ 1e2] -grecord-gcc-switches
[ 1f8] -ggdb
[ 202] -frecord-gcc-switches
$ size /usr/bin/sqlite3
textdata bss dec hex filename
445454124 328 48997bf65 /usr/bin/sqlite3
And with -fno-unwind...
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep unwind\|-g
[ 1e2] -grecord-gcc-switches
[ 1f8] -ggdb
[ 202] -frecord-gcc-switches
[ 218] -fno-unwind-tables
[ 22b] -fno-asynchronous-unwind-tables
$ size /usr/bin/sqlite3
textdata bss dec hex filename
427134124 328 47165b83d /usr/bin/sqlite3
As you can see I have splitdebug turned on.
Marcin
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Dienstag, 18. Dezember 2012, 12:43:55 schrieb Marcin Mirosław:
W dniu 18.12.2012 12:13, Sven Eden pisze:
(snip, because this has nothing to do with the previous discussion.)
On my 32-bit machines I have...
FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables CXXFLAGS=${CFLAGS}
See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables. Would I
have to rebuild system and world without...
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
...to have debug data available?
No, you haven't, if you have compiled everything with -g or -ggdb.
According to the web page you linked, the DWARF-2 tables are then written
into the .debug files. Without -g/-ggdb, they are stripped and no longer
available for debugging.
So according to your CFLAGS, you'd have to rebuild everything, yes, but a
simple -g would do.
Oh, and splitdebug in FEATURES would be a good idea, too! ;)
Hi Sven!
Meseems you are not right, please look at it:
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep unwind\|-g
[ 1e2] -grecord-gcc-switches
[ 1f8] -ggdb
[ 202] -frecord-gcc-switches
$ size /usr/bin/sqlite3
textdata bss dec hex filename
445454124 328 48997bf65 /usr/bin/sqlite3
And with -fno-unwind...
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep unwind\|-g
[ 1e2] -grecord-gcc-switches
[ 1f8] -ggdb
[ 202] -frecord-gcc-switches
[ 218] -fno-unwind-tables
[ 22b] -fno-asynchronous-unwind-tables
$ size /usr/bin/sqlite3
textdata bss dec hex filename
427134124 328 47165b83d /usr/bin/sqlite3
As you can see I have splitdebug turned on.
Marcin
Hi Marcin,
I am not right with what? All I did was interpreting a quoted link. And what
is this supposed to mean? So /usr/bin/sqlite3 looses size. Yes. This goes
along with the quoted link. But did you compare the current size of
/usr/lib64/debug/usr/bin/sqlite3.debug before and after?
Sorry for any inconvenience, but I assure you, I have absolutly no idea what
you intent to show.
Sincerly
Sven
--
http://pwxlib.sourceforge.net
signature.asc
Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
W dniu 18.12.2012 13:03, Sven Eden pisze:
Am Dienstag, 18. Dezember 2012, 12:43:55 schrieb Marcin Mirosław:
W dniu 18.12.2012 12:13, Sven Eden pisze:
(snip, because this has nothing to do with the previous discussion.)
On my 32-bit machines I have...
FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables CXXFLAGS=${CFLAGS}
See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables. Would I
have to rebuild system and world without...
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
...to have debug data available?
No, you haven't, if you have compiled everything with -g or -ggdb.
According to the web page you linked, the DWARF-2 tables are then written
into the .debug files. Without -g/-ggdb, they are stripped and no longer
available for debugging.
So according to your CFLAGS, you'd have to rebuild everything, yes, but a
simple -g would do.
Oh, and splitdebug in FEATURES would be a good idea, too! ;)
Hi Sven!
Meseems you are not right, please look at it:
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep unwind\|-g
[ 1e2] -grecord-gcc-switches
[ 1f8] -ggdb
[ 202] -frecord-gcc-switches
$ size /usr/bin/sqlite3
textdata bss dec hex filename
445454124 328 48997bf65 /usr/bin/sqlite3
And with -fno-unwind...
$ readelf -p .GCC.command.line /usr/lib64/debug/usr/bin/sqlite3.debug
|grep unwind\|-g
[ 1e2] -grecord-gcc-switches
[ 1f8] -ggdb
[ 202] -frecord-gcc-switches
[ 218] -fno-unwind-tables
[ 22b] -fno-asynchronous-unwind-tables
$ size /usr/bin/sqlite3
textdata bss dec hex filename
427134124 328 47165b83d /usr/bin/sqlite3
As you can see I have splitdebug turned on.
Marcin
Hi Marcin,
Hi Sven!
I am not right with what? All I did was interpreting a quoted link. And what
is this supposed to mean? So /usr/bin/sqlite3 looses size. Yes. This goes
along with the quoted link. But did you compare the current size of
/usr/lib64/debug/usr/bin/sqlite3.debug before and after?
My fault, I didn't respond below correct paragraph. I was thinking about:
According to the web page you linked, the DWARF-2 tables are then written
into
the .debug files. Without -g/-ggdb, they are stripped and no longer
available
for debugging.
I tried to show that without -g/-ggdb gcc generates DWARF-2 tables and
strip doesn't remove it from binaries. I pasted examples with sqlite3
compiles with -ggdb but I'm getting the same results without debug
flags. When I add -fno-unwind-tables and -fno-asynchronous-unwind-tables
I'm getting smaller size of text (and all binary also).
And I agree with all you write about recompiling system with -g and
splitdebug.
Hmm, now I think you was thinking only about adding debug information to
Walters' gentoo and didn't want to talk about growing eh_frame...
Sorry for any inconvenience, but I assure you, I have absolutly no idea what
you intent to show.
I hope I throwed some light on my earlier answer.
regards,
Marcin
Re: [gentoo-dev] Defaulting for debug information in profiles
Il 17/12/2012 11:11, Tomáš Chvátal ha scritto: Hi lads, lately I am having bit of problems from getting relevant debug info from users. Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not that bad with current disk sizes and it saves users quite some time when i have to request them to recompile half of their system with debug info just to get idea how to fix their issue. I would go even for compressdebug feature but that one needs more time as some packages like glibc fails to merge with it and you need newer gdb to work with it. Cheers Tom By the way gcc-4.8 will have support for -gsplit-dwarf, should be something similar to split-debug, just done pre linking and with different file names. While I've no idea how this feature work, probably start planning would be beneficial. -gsplit-dwarf Separate as much dwarf debugging information as possible into a separate output file with the extension .dwo. This option allows the build system to avoid linking files with debug information. To be useful, this option requires a debugger capable of reading .dwo files. Also thinking about this a bit more, seem a binpkg for debug stuff can be interesting, similarly to how binary distro do. rogue example implementation: with FEATURE=buildpkg split-debug-pkg all the /usr/lib/debug and /usr/src/debug files are put in a separate package debug/category/pn or similarly to sec-policy/selinux* debug/cat--pn the user can then install debug packages at will, the dependancies should work (and clone those of the real package) but not be mandatory. how difficult would be to implement this in portage (keep in mind that packages are coupled and should stay that way also for unmerge and whatever)? Would be possible to have FEATURE= -buildpkg split-debug-pkg? A similar feature would be useful for linguas support but more difficult to implement.
Re: [gentoo-dev] Defaulting for debug information in profiles
El lun, 17-12-2012 a las 08:55 -0500, Rich Freeman escribió: [...] I usually keep a debug file in /etc/portage/env.d and symlink it to anything I'm working on. Rich I do the same, for example, I had end.d files for all evince related packages to get proper backtraces as I was getting crashes from time to time for some files signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17/12/2012 11:11, Tomáš Chvátal wrote: Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. Why, somebody uses default cflags? -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu: On 17/12/2012 11:11, Tomáš Chvátal wrote: Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. Why, somebody uses default cflags? I silently hope they copy the default cflags to their make.conf and then set march and add more stuff, rather than starting from scratch. Also we can pop-up newsitem asking them to put it into cflags ;-)
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Montag, 17. Dezember 2012, 11:11:38 schrieb Tomáš Chvátal: Hi lads, lately I am having bit of problems from getting relevant debug info from users. Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not (snip) Hello Tomáš, on my system I have set up everything with splitdebug enabled. My CFLAGS use - march=native, -O2 and -ggdb. And this is the result: (Yes, I have a dedictated partition for that.) ~ $ LC_ALL=C df -h /usr/lib/debug/. Filesystem Size Used Avail Use% Mounted on /dev/sda10 25G 22G 1.7G 93% /usr/lib64/debug This is a full KDE-4.9.4 system with a total of 1,807 packages installed. I guess the regular user would end up somewhere between your 2G and my 22G. But I bet it will be slightly more likely my end, wouldn't it? Sincerly Sven -- http://pwxlib.sourceforge.net signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17 December 2012 18:26, Tomáš Chvátal tomas.chva...@gmail.com wrote: 2012/12/17 Diego Elio Pettenò flamee...@flameeyes.eu: On 17/12/2012 11:11, Tomáš Chvátal wrote: Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. Why, somebody uses default cflags? I silently hope they copy the default cflags to their make.conf and then set march and add more stuff, rather than starting from scratch. Also we can pop-up newsitem asking them to put it into cflags ;-) Please don't. For most users this is a waste of resources. -- Cheers, Ben | yngwin Gentoo developer Gentoo Qt project lead, Gentoo Wiki admin
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17/12/2012 11:33, Sven Eden wrote: on my system I have set up everything with splitdebug enabled. My CFLAGS use - march=native, -O2 and -ggdb. That's -ggdb that increases the size. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/ signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17/12/2012 11:26, Tomáš Chvátal wrote: I silently hope they copy the default cflags to their make.conf and then set march and add more stuff, rather than starting from scratch. Also we can pop-up newsitem asking them to put it into cflags ;-) They don't, they use those coming from cataylist. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Defaulting for debug information in profiles
On Mon, 2012-12-17 at 11:11 +0100, Tomáš Chvátal wrote: Hi lads, lately I am having bit of problems from getting relevant debug info from users. Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not that bad with current disk sizes and it saves users quite some time when i have to request them to recompile half of their system with debug info just to get idea how to fix their issue. I would go even for compressdebug feature but that one needs more time as some packages like glibc fails to merge with it and you need newer gdb to work with it. Cheers Tom The bigger problem is not disk space but memory usage at link time. Try building something like *-webkit-* or firefox with debugging CFLAGS on a machine with limited memory.
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Sven Eden sven.e...@gmx.de: Hello Tomáš, on my system I have set up everything with splitdebug enabled. My CFLAGS use - march=native, -O2 and -ggdb. And this is the result: (Yes, I have a dedictated partition for that.) ~ $ LC_ALL=C df -h /usr/lib/debug/. Filesystem Size Used Avail Use% Mounted on /dev/sda10 25G 22G 1.7G 93% /usr/lib64/debug This is a full KDE-4.9.4 system with a total of 1,807 packages installed. I guess the regular user would end up somewhere between your 2G and my 22G. But I bet it will be slightly more likely my end, wouldn't it? Well your problem is using -ggdb, that adds ton of stuff that makes things large exponencialy in most cases, i bet you would be around 5-6 on -g usage. Cheers Tom
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Alexandre Rostovtsev tetrom...@gentoo.org: The bigger problem is not disk space but memory usage at link time. Try building something like *-webkit-* or firefox with debugging CFLAGS on a machine with limited memory. That ain't problem, we acutally can patch in those packages to strip the debug by default and add there useflag to not strip those for those really needing it. Also the culprit is again -ggdb rather than -g.
Re: [gentoo-dev] Defaulting for debug information in profiles
2012/12/17 Ben de Groot yng...@gentoo.org: Please don't. For most users this is a waste of resources. On first look it seems like waste of resources. On second hand it makes stuff easy wrt bugreports provided by users. And believe me when I say most upstreams are pissed by gentoo reports because they lack any good debuginfo features, nor they know how to tell users how to make their systems contain debug informations. I have seen quite few upstreams rejecting all by Gentoo reported issues because of this, plus they were quite suprised that I actually can generate any sane debug informations with it.
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17/12/2012 11:54, Tomáš Chvátal wrote: That ain't problem, we acutally can patch in those packages to strip the debug by default and add there useflag to not strip those for those really needing it. No. USE=debug is for _something else_ entirely. And I'm going to kick hard whoever tries to make USE=debug provide debug information rather than debug codepaths. Also the culprit is again -ggdb rather than -g. Which makes now interesting for somebody to test what webkit-gtk requires, memory-wise, with just -g rather than -ggdb. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Defaulting for debug information in profiles
Il 17/12/2012 11:42, Diego Elio Pettenò ha scritto:
On 17/12/2012 11:33, Sven Eden wrote:
on my system I have set up everything with splitdebug enabled. My CFLAGS use -
march=native, -O2 and -ggdb.
That's -ggdb that increases the size.
In short FEATURES=compressdebug should be stable and default before you
(gentoo) decide for something like this.
As mentioned somewhere else in this thread some packages are on the
unbeareable side when compiled with debug information, those should
default to filter out debug flags if not actually wanted by the user
USE=gdb maybe?
When going with debug information the best available should be used so
-ggdb not -g if possible.
Please try to understand the differences between the various options
(nodebug, -g, -ggdb) versus (time to build, memory needed, disk space)
before attempting this.
Diego maybe it's worth some runs in the tinderbox.
Some numbers:
Packages installed: 1756
Packages in world:626
Packages in system: 42
Required packages:1756
Number to remove: 0
ECFLAGSbase='-O2 -march=corei7-avx -pipe -frecord-gcc-switches'
ECFLAGSnative='-mno-movbe -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop
-mno-bmi -mno-tbm --param=l1-cache-size=32 --param=l1-cache-line-size=64
--param=l2-cache-size=6144 -mtune=corei7-avx'
ECFLAGSnative=${ECFLAGSnative} -mno-bmi2 -mno-avx2 -mno-lzcnt -mrdrnd
--param=l1-cache-size=32
ECFLAGSo3='-fgcse-after-reload -fpredictive-commoning -ftree-vectorize
-funswitch-loops' # O3 - -finline-functions -fipa-cp-clone
ECFLAGSgraphite='-fgraphite-identity -floop-block -floop-interchange
-floop-strip-mine' # graphite co (-fira-loop-pressure no good amd64)
ECFLAGSdbug='-ggdb -gdwarf-4 -fvar-tracking-assignments'
ECFLAGSlto=''
CFLAGS=${ECFLAGSbase} ${ECFLAGSnative} ${ECFLAGSo3} ${ECFLAGSgraphite}
${ECFLAGSlto} ${ECFLAGSdbug}
CXXFLAGS=${CFLAGS} -fvisibility-inlines-hidden
ELDFLAGSoptimize='-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-Wl,--sort-common -Wl,--no-copy-dt-needed-entries'
ELDFLAGSdebug='-Wl,--build-id'
ELDFLAGSlto=''
LDFLAGS=${LDFLAGS} ${ELDFLAGSoptimize} ${ELDFLAGSdebug}
FEATURES=${FEATURES} splitdebug installsources compressdebug
du -csh /usr/lib/debug/ /usr/src/debug/
5,5G/usr/lib/debug/
3,9G/usr/src/debug/
9,4Gtotale
find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec
echo {} +
/usr/armv7a-hardfloat-linux-gnueabi /usr/bin /usr/brlcad /usr/data
/usr/etc /usr/fakelib /usr/gnu-classpath-0.98 /usr/include /usr/lib32
/usr/lib64 /usr/libexec /usr/local /usr/man /usr/Mod /usr/sbin
/usr/share /usr/x86_64-pc-linux-gnueabi
find /usr/* -maxdepth 0 -type d -not -name src -not -name portage -exec
du -csh {} +
38M /usr/armv7a-hardfloat-linux-gnueabi
825M/usr/bin
86M /usr/brlcad
1,3M/usr/data
16K /usr/etc
8,0K/usr/fakelib
12M /usr/gnu-classpath-0.98
425M/usr/include
392M/usr/lib32
11G /usr/lib64 == 5,5G/usr/lib/debug/
415M/usr/libexec
28K /usr/local
304K/usr/man
18M /usr/Mod
81M /usr/sbin
3,3G/usr/share
27M /usr/x86_64-pc-linux-gnu
17G totale
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17/12/2012 12:37, viv...@gmail.com wrote: In short FEATURES=compressdebug should be stable and default before you (gentoo) decide for something like this. As mentioned somewhere else in this thread some packages are on the unbeareable side when compiled with debug information, those should default to filter out debug flags if not actually wanted by the user USE=gdb maybe? When going with debug information the best available should be used so -ggdb not -g if possible. Please try to understand the differences between the various options (nodebug, -g, -ggdb) versus (time to build, memory needed, disk space) before attempting this. Diego maybe it's worth some runs in the tinderbox. Again, I'm against using USE flags to handle debug information, it's already hard enough as it is without adding extra complexity. I'd be more for _suggesting_ the use of -g but leaving it to the user. And yes I also agree that -ggdb makes more sense. I'll write something about it later on I guess. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Defaulting for debug information in profiles
On Mon, Dec 17, 2012 at 11:26 AM, Tomáš Chvátal tomas.chva...@gmail.com wrote: I silently hope they copy the default cflags to their make.conf and then set march and add more stuff, rather than starting from scratch. Also we can pop-up newsitem asking them to put it into cflags ;-) You might want to get the handbook to recommend that for new installs? http://www.gentoo.org/doc/en/handbook/handbook-amd64.xml?part=1chap=5#doc_chap3 Cheers, Dirkjan
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17 December 2012 10:11, Tomáš Chvátal tomas.chva...@gmail.com wrote: Hi lads, lately I am having bit of problems from getting relevant debug info from users. Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not that bad with current disk sizes and it saves users quite some time when i have to request them to recompile half of their system with debug info just to get idea how to fix their issue. I would go even for compressdebug feature but that one needs more time as some packages like glibc fails to merge with it and you need newer gdb to work with it. Cheers Tom Sounds like a reasonable request to me although most people will have their own cflags in make.conf. -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] Defaulting for debug information in profiles
Am Montag, 17. Dezember 2012, 11:47:24 schrieb Tomáš Chvátal: 2012/12/17 Sven Eden sven.e...@gmx.de: Hello Tomáš, on my system I have set up everything with splitdebug enabled. My CFLAGS use - march=native, -O2 and -ggdb. And this is the result: (Yes, I have a dedictated partition for that.) ~ $ LC_ALL=C df -h /usr/lib/debug/. Filesystem Size Used Avail Use% Mounted on /dev/sda10 25G 22G 1.7G 93% /usr/lib64/debug This is a full KDE-4.9.4 system with a total of 1,807 packages installed. I guess the regular user would end up somewhere between your 2G and my 22G. But I bet it will be slightly more likely my end, wouldn't it? Well your problem is using -ggdb, that adds ton of stuff that makes things large exponencialy in most cases, i bet you would be around 5-6 on -g usage. First, I do not want to argue. I just want to state, and prove for at least _my_ machine, that this is not true. Second, my whole system is compiled using gcc-4.7.2. This means, that the results below might differ greatly from a setting where stable gcc-4.5.4 is used for the whole. But this doesn't matter, because gcc-4.7.* will, eventually, become the stable and current gcc. (Unless it is skipped, of course.) Third, _My_ Machine means: My setting, hardware, USE-Flags and CFLAGS. For this the assumption -ggdb would add about 300% in size is a bit exsessive. Background: The option -g produces debugging information in the operating systems native format, already fit for GDB. -ggdb simply uses the most expressive format. Both, as I believe, result in DWARF-2 format on my system. At least I get no difference whether I specify -g -gdwarf-2 or -ggdb. GDB extensions are added if possible. It seems to me, judging the results of the tests below, that those gdb- extensions are already enabled by default (gcc-4.7.2). I have not found any information on that regarding DWARF-2, but at least http://gcc.gnu.org/onlinedocs/gccint/DBX-Options.html states that DEFAULT_GDB_EXTENSIONS (for DBX output) is always turned on by default. Maybe that's true for DWARF-2 as well? Below are the resulting sizes of all .debug files having been generated first using -ggdb, then using -g in make.conf CFLAGS. The tested packages are: 1) kde-base/kate (C++ Code, heavy library usage) and 2) dev-libs/lzo (ANSI C) I believe both are, regarding their code base, far enough apart for building up a test case. It is _not_ representative, of course. 1) --- kde-base/kate - Compiled with -ggdb in CFLAGS: # sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum 32652140 Compiled with -g in CFLAGS: # sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum 32652140 Result: No size change at all. 2) --- dev-libs/lzo - Compiled with -ggdb in CFLAGS: # sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum 558664 Compiled with -g in CFLAGS: # sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum 558304 Result: A difference of 260 bytes or 0.06%. Far away from the assumed 300%. Conclusion: I do not doubt that -ggdb adds size. It does. And maybe, if I did an emerge -e @world would reduce the size used on my system between 30% and 40%. But not about 66% like assumed. However, even if it where around 5-6 G, it would be thrice the initial assumption of 2G. And that's the whole point. Sincerly Sven signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Defaulting for debug information in profiles
On 12/17/2012 11:11 AM, Tomáš Chvátal wrote: Hi lads, lately I am having bit of problems from getting relevant debug info from users. All trouble can be saved by asking user to recompile package with relevant flags on bug report, resolving the bug as NEEDINFO. Instead of forcing everybody out there using Gentoo to have additional XGb for debug, patching troublesome packages like webkit-gtk etc. Bug without valid data is by definition... invalid? I'm pretty amused by this thread, cause *you* taught me that ^^. I had once the very same idea :) Cheers, Kacper Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. This results in 2 gb data in /usr/lib/debug for my system which is not that bad with current disk sizes and it saves users quite some time when i have to request them to recompile half of their system with debug info just to get idea how to fix their issue. I would go even for compressdebug feature but that one needs more time as some packages like glibc fails to merge with it and you need newer gdb to work with it. Cheers Tom signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Defaulting for debug information in profiles
On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik xarthis...@gentoo.org wrote: All trouble can be saved by asking user to recompile package with relevant flags on bug report, resolving the bug as NEEDINFO. Instead of forcing everybody out there using Gentoo to have additional XGb for debug, patching troublesome packages like webkit-gtk etc. Bug without valid data is by definition... invalid? Tend to agree. Plus, you can always compile -O0 in such a case and get more useful debug info besides (yes, I know this can be misleading under some circumstances, but not all packages are glibc). Plus, if the user doesn't enable core dumps the debug info is useless unless the problem is reproducible, and if it is reproducible then you can just build it with debug info. But, by all means make it easy for the user to make their own choice. I usually keep a debug file in /etc/portage/env.d and symlink it to anything I'm working on. Rich
Re: [gentoo-dev] Defaulting for debug information in profiles
On Mon, Dec 17, 2012 at 9:05 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: So please stop giving this stupid suggestion, which causes enough grief as it is without being repeated once again. Uh, sure, insofar as it is possible to stop doing something that you've done exactly once... :) However, I've found it a useful tool, assuming the error is still reproducible. If it prevents the error from being reproduced it is obviously less useful. I for one like having all parameters on my stack frame, but perhaps there is another switch that will only toggle this. Rich
Re: [gentoo-dev] Defaulting for debug information in profiles
On 17/12/2012 15:20, Rich Freeman wrote: Uh, sure, insofar as it is possible to stop doing something that you've done exactly once... :) In general, I've heard the same suggestion touted too many times already. It's this kind of misinformation and cargo culting that often causes `strip-flags` to be used (even when gcc codegen is perfectly fine), or that make upstream complain that Gentoo users are ricers for not sticking with -O0. However, I've found it a useful tool, assuming the error is still reproducible. If it prevents the error from being reproduced it is obviously less useful. By experience with the kind of crashes we get reported on bugzilla, roughly eight times out of ten it's perfectly pointless to use -O0. _FORTIFY_SOURCES overflows can't happen at -O0. Uninitialized variables are zeroed out at -O0. At -O0 you're debugging a completely different program. Sure it's possible that the crash is so blatantly broken than it will crash anyway, but that kind of crashes tend to be extremely rare and easy to catch to begin with. In most cases, you just want to know the ballpark of where the crash is happening, as you want to know which assumption is not holding up. I for one like having all parameters on my stack frame, but perhaps there is another switch that will only toggle this. There is, but it can stop constant propagation from working properly. If we're discussing about crashes, which is what debug information in general is useful for, -O0 is useless in most cases. It's a different story altogether if you go into what a developer would do to debug a particularly nasty crash, or to see why something's misbehaving, and you want to use gdb rather than fill your code of printf() statements. But that's a completely different story, so let's leave it at that. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] Defaulting for debug information in profiles
On 12/17/12 2:11 AM, Tomáš Chvátal wrote: Since we already have splitdebug for quite time (and I suppose quite few of us are using it) how about making it to default profiles default enabled and add -g to default cflags. Currently it is only enabled in the developer profile. Fully seconded. For people raising concerns in this thread: it can be easily disabled. I think good defaults are really important. What do you think is more reasonable to assume: (1) that the user hits crashes and wants to submit a good bug report but doesn't want to recompile half of the system, or (2) that the user has very limited disk space or some other kind of special configurations. Note that (2) is totally fine, I just think it's less likely to happen (hopefully we can avoid a bias here with people thinking if _they_ have a setup that can't use splitdebug or something, the same would apply to everybody else). Paweł signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Defaulting for debug information in profiles
On Mon, Dec 17, 2012 at 01:37:27PM +0100, Sven Eden wrote
1) --- kde-base/kate
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f kde-base/kate | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
32652140
Result: No size change at all.
2) --- dev-libs/lzo
-
Compiled with -ggdb in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558664
Compiled with -g in CFLAGS:
# sum=0; for file in $(equery f dev-libs/lzo | grep \.debug) ; do
xSize=$(stat -c %s $file) ; sum=$((sum+xSize)) ; done ; echo $sum
558304
Result: A difference of 260 bytes or 0.06%. Far away from the assumed 300%.
Conclusion:
I do not doubt that -ggdb adds size. It does. And maybe, if I did an emerge
-e
@world would reduce the size used on my system between 30% and 40%. But not
about 66% like assumed.
However, even if it where around 5-6 G, it would be thrice the initial
assumption of 2G. And that's the whole point.
On my 32-bit machines I have...
FLAGS=-O2 -march=native -mfpmath=sse -fomit-frame-pointer -pipe
-fno-unwind-tables -fno-asynchronous-unwind-tables
CXXFLAGS=${CFLAGS}
See http://comments.gmane.org/gmane.linux.busybox/36695 for why I
include -fno-unwind-tables -fno-asynchronous-unwind-tables. Would I
have to rebuild system and world without...
-fomit-frame-pointer -fno-unwind-tables -fno-asynchronous-unwind-tables
...to have debug data available?
--
Walter Dnes waltd...@waltdnes.org
I don't run desktop environments; I run useful applications
Re: [gentoo-dev] Defaulting for debug information in profiles
On 12/17/2012 02:55 PM, Rich Freeman wrote: On Mon, Dec 17, 2012 at 8:43 AM, Kacper Kowalik xarthis...@gentoo.org wrote: All trouble can be saved by asking user to recompile package with relevant flags on bug report, resolving the bug as NEEDINFO. Instead of forcing everybody out there using Gentoo to have additional XGb for debug, patching troublesome packages like webkit-gtk etc. Bug without valid data is by definition... invalid? Tend to agree. Plus, you can always compile -O0 in such a case and Ages ago I wrote something about how wrong is using -O0 and expect to reproduce issues. IIRC Diego blogged about it as well. Please do not use -O0, it changes a _lot_ the codepats of programs and glibc (and other libc) might or might not switch to compiler specific implementation that might uncover problems. I'd rather suggest the user to install valgrind and run the application under it. lu
