The object files produced with current portage (2.1.2.7) using the flag 'stripdebug' still contain the debug sections: # readelf -S /lib/ld-2.5.so There are 34 section headers, starting at offset 0x7ffd4: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .hash HASH 00000114 000114 00013c 04 A 2 0 4 [ 2] .dynsym DYNSYM 00000250 000250 000280 10 A 3 10 4 [ 3] .dynstr STRTAB 000004d0 0004d0 0001a8 00 A 0 0 1 [ 4] .gnu.version VERSYM 00000678 000678 000050 02 A 2 0 2 [ 5] .gnu.version_d VERDEF 000006c8 0006c8 0000ec 00 A 3 7 4 [ 6] .rel.dyn REL 000007b4 0007b4 000060 08 A 2 0 4 [ 7] .rel.plt REL 00000814 000814 000028 08 A 2 8 4 [ 8] .plt PROGBITS 0000083c 00083c 000060 04 AX 0 0 4 [ 9] .text PROGBITS 000008a0 0008a0 014cef 00 AX 0 0 16 [10] __libc_freeres_fn PROGBITS 00015590 015590 000127 00 AX 0 0 16 [11] .rodata PROGBITS 000156c0 0156c0 003ac0 00 A 0 0 32 [12] .eh_frame_hdr PROGBITS 00019180 019180 000124 00 A 0 0 4 [13] .eh_frame PROGBITS 000192a4 0192a4 000458 00 A 0 0 4 [14] .data.rel.ro PROGBITS 0001ac80 019c80 00027c 00 WA 0 0 32 [15] .dynamic DYNAMIC 0001aefc 019efc 0000c0 08 WA 3 0 4 [16] .got PROGBITS 0001afbc 019fbc 000028 04 WA 0 0 4 [17] .data PROGBITS 0001b000 01a000 000604 00 WA 0 0 32 [18] __libc_subfreeres PROGBITS 0001b604 01a604 000004 00 WA 0 0 4 [19] .bss NOBITS 0001b608 01a608 0000c0 00 WA 0 0 8 [20] .comment PROGBITS 00000000 01a608 000528 00 0 0 1 [21] .debug_aranges PROGBITS 00000000 01ab30 0004d0 00 0 0 1 [22] .debug_pubnames PROGBITS 00000000 01b000 000c09 00 0 0 1 [23] .debug_info PROGBITS 00000000 01bc09 03ec20 00 0 0 1 [24] .debug_abbrev PROGBITS 00000000 05a829 005ff1 00 0 0 1 [25] .debug_line PROGBITS 00000000 06081a 007820 00 0 0 1 [26] .debug_frame PROGBITS 00000000 06803c 001410 00 0 0 4 [27] .debug_str PROGBITS 00000000 06944c 004669 01 MS 0 0 1 [28] .debug_loc PROGBITS 00000000 06dab5 00f1cc 00 0 0 1 [29] .debug_ranges PROGBITS 00000000 07cc81 0031e0 00 0 0 1 [30] .gnu_debuglink PROGBITS 00000000 07fe61 000014 00 0 0 1 [31] .shstrtab STRTAB 00000000 07fe75 00015d 00 0 0 1 [32] .symtab SYMTAB 00000000 080524 002210 10 33 515 4 [33] .strtab STRTAB 00000000 082734 001bb5 00 0 0 1 # readelf -S /usr/lib/debug/lib/ld-2.5.so.debug There are 33 section headers, starting at offset 0x66628: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [ 0] NULL 00000000 000000 000000 00 0 0 0 [ 1] .hash NOBITS 00000114 000114 00013c 00 A 0 0 4 [ 2] .dynsym NOBITS 00000250 000114 000280 00 A 0 0 4 [ 3] .dynstr NOBITS 000004d0 000114 0001a8 00 A 0 0 1 [ 4] .gnu.version NOBITS 00000678 000114 000050 00 A 0 0 2 [ 5] .gnu.version_d NOBITS 000006c8 000114 0000ec 00 A 0 0 4 [ 6] .rel.dyn NOBITS 000007b4 000114 000060 00 A 0 0 4 [ 7] .rel.plt NOBITS 00000814 000114 000028 00 A 0 0 4 [ 8] .plt NOBITS 0000083c 000114 000060 00 AX 0 0 4 [ 9] .text NOBITS 000008a0 000114 014cef 00 AX 0 0 16 [10] __libc_freeres_fn NOBITS 00015590 000114 000127 00 AX 0 0 16 [11] .rodata NOBITS 000156c0 000114 003ac0 00 A 0 0 32 [12] .eh_frame_hdr NOBITS 00019180 000114 000124 00 A 0 0 4 [13] .eh_frame NOBITS 000192a4 000114 000458 00 A 0 0 4 [14] .data.rel.ro NOBITS 0001ac80 000c80 00027c 00 WA 0 0 32 [15] .dynamic NOBITS 0001aefc 000c80 0000c0 00 WA 0 0 4 [16] .got NOBITS 0001afbc 000c80 000028 00 WA 0 0 4 [17] .data NOBITS 0001b000 000c80 000604 00 WA 0 0 32 [18] __libc_subfreeres NOBITS 0001b604 000c80 000004 00 WA 0 0 4 [19] .bss NOBITS 0001b608 000c80 0000c0 00 WA 0 0 8 [20] .comment PROGBITS 00000000 000c80 000528 00 0 0 1 [21] .debug_aranges PROGBITS 00000000 0011a8 0004d0 00 0 0 1 [22] .debug_pubnames PROGBITS 00000000 001678 000c09 00 0 0 1 [23] .debug_info PROGBITS 00000000 002281 03ec20 00 0 0 1 [24] .debug_abbrev PROGBITS 00000000 040ea1 005ff1 00 0 0 1 [25] .debug_line PROGBITS 00000000 046e92 007820 00 0 0 1 [26] .debug_frame PROGBITS 00000000 04e6b4 001410 00 0 0 4 [27] .debug_str PROGBITS 00000000 04fac4 004669 01 MS 0 0 1 [28] .debug_loc PROGBITS 00000000 05412d 00f1cc 00 0 0 1 [29] .debug_ranges PROGBITS 00000000 0632f9 0031e0 00 0 0 1 [30] .shstrtab STRTAB 00000000 0664d9 00014e 00 0 0 1 [31] .symtab SYMTAB 00000000 066b50 002200 10 32 514 4 [32] .strtab STRTAB 00000000 068d50 001bb5 00 0 0 1 Reproducible: Always Steps to Reproduce: 1. use stripdebug 2. check out the object files :) 3.
There is no 'stripdebug' flag, you probably mean either 'splitdebug' or 'nostrip'
Yap, typo. Sorry.
I mean, it's a typo in the bug report. Doesn't change a bit on the matter itself.
Post your emerge --info please. Do you have nostrip in FEATURES? That would do it. FYI, the relevant strip command happens inside /usr/lib/portage/bin/prepstrip.
Actually, nostrip disables splitdebug, so that can't be the problem.
It happens on two of my systems, here's the emerge --info of the notebook: $ emerge --info Portage 2.1.2.7 (default-linux/x86/2007.0/desktop, gcc-4.1.2, glibc-2.5-r2, 2.6.20-gentoo-r6 i686) ================================================================= System uname: 2.6.20-gentoo-r6 i686 Intel(R) Pentium(R) M processor 1.73GHz Gentoo Base System release 1.12.10 Timestamp of tree: Thu, 17 May 2007 14:00:01 +0000 dev-java/java-config: 1.3.7, 2.0.32 dev-lang/python: 2.4.4-r4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.16 sys-devel/libtool: 1.5.23b virtual/os-headers: 2.6.21 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=pentium-m -pipe -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=pentium-m -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks install-sources metadata-transfer parallel-fetch sfperms splitdebug strict userpriv" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LINGUAS="en" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --filter=H_**/files/digest-*" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi alsa amr apache2 asf audiofile bash-completion bitmap-fonts bl boundschecking browserplugin bzip2 cairo cddb cdparanoia cdr cli cpudetection cracklib crypt css cups dbus dga dlloader doc dri dts dv dvb dvd dvdr dvdread dynagraph edl eds emboss encode evo examples extraengine fam ffmpeg firefox flac fortran gdbm gif gimp glib glitz gnutls gps graphviz gs hal iconv ieee1394 imagemagick inkjar isdnlog jack jce jpeg jpeg2k kde kdeenablefinal lcms libg++ lm_sensors logitech-mouse lzo mad matroska midi mikmod mjpeg mmx mmxext mng mod modplug mozdevelop mp2 mp3 mp4 mpeg mplayer mudflap musepack musicbrainz ncurses network nls nodrm nptl nptlonly nsplugin nvidia offensive ogg openexr opengl osc pam pango pcre pda pdf perl png pnm povray pppd python qt3support quicktime rdesktop readline real reflection rtc scanner sdl session shout sndfile spl sse sse2 ssl svg swat tcpd tetex theora tidy tiff truetype truetype-fonts type1-fonts unicode usb userlocales v4l v4l2 vcd vhosts vorbis wifi win32codecs wmf x264 x86 xinerama xml xorg xrandr xv xvid xvmc zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, PORTDIR_OVERLAY
Yap, I already checked out prepstrip, but couldn't find the cause on short notice. I encountered the problem because valgrind didn't work anymore (aborts due to duplicate sections) and had to fix this quickly by running strip on the involved object files by hand.
has nothing to do with portage ... glibc ebuild purposefully does not strip ldso
No he's right, there's a bug with prepstrip: it generates the debug info even for the files in STRIP_MASK.
the report is that the file "/lib/ld-2.5.so" is not stripped even though he has FEATURES=stripdebug which is invalid ... glibc does not strip those files as for generating debug sections for files masked for stripping, i say that's a feature, not a bug
Well, fact #1: The behaviour is not the expected one fact #2: The behaviour has been changed lately to _not_ strip the debug sections. I won't argue about this anymore, I strip them manually and that's it for me.
your definition of "lately" must differ greatly from the commonly accepted one glibc has not been stripping that file for almost 2 years
Created attachment 120950 [details, diff] Don't split debug out for files with I disagree with creating .debug files (and .gnu_debuglink sections) for non-stripped files. I'm attaching a patch to portage to fix the issue, as having a .gnu_debuglink section for a file that has its debug sections inline doesn't feel right at all (beside wasting space to duplicate data). An alternative would be to sever the debuglink by passing -R .gnu_debuglink to strip, but I don't really like having to waste double space for glibc. This is alike to stripping/splitting pre-stripped files, which was being done and is not done anymore.
it isnt alike ... trying to extract debug information from a stripped file is pointless as the result is completely useless storing debug information for a file that wasnt stripped will produce usable results, just duplicated ... so if the user goes ahead and strips the file, you still can debug it ... in the end, you're talking about saving less than a meg on disk here which seems like not worth the effort what i think would be a useful endeavor is to see if the reason we dont strip these friggin files in the first place (stupid gdb bug) is also fixed by stripdebug ... then you could make the case where files masked from stripping will have their debug split off and then stripped
Hard to debate if this is actually a bug or not. In one hand spanky is right here. Having that extra info stored actually has the benefit of allowing the user to post-strip any bins they deem fit. Howver the patch from flameeyes is trivial and would probably do the job, thus not waisting diskspace for no good reason. Oh and I'd assert that mainly this is a bug with valgrind not being able to cope and that should be fixed upstream.
*** Bug 179660 has been marked as a duplicate of this bug. ***
It seems the gdb problem (bug #52100) has been solved. This is what I have installed: [ebuild R ] sys-libs/glibc-2.5-r3 USE="nptl nptlonly -build -debug -glibc-compat20 -glibc-omitfp (-hardened) (-multilib) -nls -profile (-selinux)" 0 kB [ebuild R ] sys-devel/gdb-6.6-r2 USE="-nls -test -vanilla" 0 kB I propose some extra testing to see if it's also solved with the latest stable versions of glibc & gdb, so that we can remove the appropriate files from STRIP_MASK in the glibc ebuild (and thereby solve this problem).
I keep forgetting to change some fields. Sorry for the spam.
(In reply to comment #15) > Oh and I'd assert that mainly this is a bug with valgrind not being able to > cope > and that should be fixed upstream. Regardless, this is a waste of space, and fixing it does give benefit to the system (however insignificant SpanKY may consider it). That fact alone should be enough reason to apply the patch. But, in addition, it also fixes a (fatal) warning in valgrind. valgrind's warning is that there are repeated sections, and it doesn't know which to use, and rightly so. I vote for flameeyes' patch.
++flameeyes patch I have something else higher in the stack, some evolution dependency, cause this problem now and I can't valgrind evolution to fix an annoying occasional crash in gtkhtml. In short, due to this I am not able to develop on a gentoo system.
that's bs ... nothing is stopping you from stripping the files in question
And how do I find out what files are in question? And how I, taken as a user, am supposed to find that out and why doesn't it work out of the box? Then again, as a user I don't care if this is a valgrind bug, or portage bug as long as it gets fixed. And if I can freely strip the libraries myself, why can't it be done always? I did find out it was libcom_err.so.2.1 by using valgrind --verbose and seeing what it loaded last in the list reported, but I shouldn't have to do that.
(In reply to comment #22) > And if I can freely strip the libraries myself, why can't it be done always? > > I did find out it was libcom_err.so.2.1 by using valgrind --verbose and seeing > what it loaded last in the list reported, but I shouldn't have to do that. Remove splitdebug from your portage FEATURES in make.conf and it will be. The problem is that some files cannot be split into a separate debug file [1]. For these files, the proper course of action is to not strip them. Portage does this, correctly, but then copies the debug information into a split file additionally, incorrectly. This wastes space and as a side effect causes valgrind to be unable to debug any file related to it. In conclusion, WORKAROUND: Remove splitdebug from FEATURES and rebuild all world packages. RESOLUTION: Apply flameeyes' patch to portage and rebuild all world packages. 1. This is because splitting these files would cause debugging with files linking to them to break for whatever reason.
a confused valgrind is a broken valgrind -- it needs to be fixed
(In reply to comment #24) > a confused valgrind is a broken valgrind -- it needs to be fixed Agreed in full. There is a bug open on their bugzilla for the problem. The problem still exists that portage is wasting space and THAT needs to be fixed regardless of valgrind. This patch fixes it. Please provide some rationale on why you are adverse to the patch, instead of focusing on highlighting shortcomings in valgrind.
you mean you want me to copy and paste my rationale from previous comments in this bug ?
This is what I can find from this thread about what you have said on the issue: (In reply to comment #14) > in the end, you're talking about saving less than a meg > on disk here which seems like not worth the effort This "concern" hardly relevant because you're opting for a substandard solution in favor of laziness, and the patch has already been written anyways which removes this reasoning entirely. > what i think would be a useful endeavor is to see if the reason we dont strip > these friggin files in the first place (stupid gdb bug) is also fixed by > stripdebug ... then you could make the case where files masked from stripping > will have their debug split off and then stripped I don't really understand what you're saying here. Assuming you meant "splitdebug" instead of "stripdebug", then you're saying that you'll gladly work around GDB bugs in portage but not Valgrind bugs. Furthermore, working around GDB bugs or not Portage still has its own bug because it leaves duplicated information lying around on the hard disk. Stop being silly. The patch is already written, waiting to be applied.
And should I repeat what was told in comments #14 (possibly not needing this with recent gdb's), #15 and #19 (not wasting space for no good reason when splitdebug is used) that haven't seen your follow-up?...
(In reply to comment #28) > And should I repeat what was told in comments #14 (possibly not needing this > with recent gdb's), #15 and #19 (not wasting space for no good reason when > splitdebug is used) that haven't seen your follow-up?... #14: It doesn't matter whether or not STRIP_MASK is needed or not, that isn't what this bug is about. This bug is about STRIP_MASK causing additional space to be wasted on the user's machine. #15 attempts to classify this wasted space as a benefit but it is moot because facilities already exist for stripping binaries if the user desires it, and those are not using splitdebug. #19 is the comment where I say what I proceeded to say in every following comment, which is that this is a bug that needs to be fixed. Yes, please copy and paste exactly what your rationale is form your previous comments. Although I would prefer it if you would rewrite and rephrase them, since I'm just restating myself and you don't seem to be acknowledging what I'm saying. It must be my misunderstanding you, so please try again. Also, are you able to commit changes to the portage code base? If so, are you solely responsible for it?
(In reply to comment #29) > Yes, please copy and paste exactly what your rationale is form your previous > comments. Although I would prefer it if you would rewrite and rephrase them, > since I'm just restating myself and you don't seem to be acknowledging what I'm > saying. It must be my misunderstanding you, so please try again. Was this directed at me? There were so many comments done to this bug in a very short time so I got confused and thought comment #26 was directed at me while it wasn't and I simply had somehow managed to miss many comments in the middle plus collision-detect only showed one of them when there were really many. As for comment #23: > WORKAROUND: Remove splitdebug from FEATURES and rebuild all world packages. > RESOLUTION: Apply flameeyes' patch to portage and rebuild all world packages. The workaround is completely out of the question for me, as that means I will have huge binaries used at runtime, always mapped in (and likely also some extra paged in) when running and not just when needed, and so on. That's because I would have nostrip then (when without splitdebug) because without debug symbols the system is useless for development even more for me. Hence I'm waiting for the resolution here being applied in the tree. > Also, are you able to commit changes to the portage code base? If so, are you > solely responsible for it? I assume this question is for SpanKY. I don't touch portage myself. However I can CC the portage developers finally, as this doesn't seem to have been done yet.
This whole discussion is moot if the bug in gdb has been solved. Spanky, is bug #52100 the only reason we're not stripping these files? I tried gdb 6.1, 6.3 and 6.6 and can't reproduce it on glibc-2.5-r4, which is stable on practically all arches.
i didnt say i was ok with working around the GDB bug, another person merged those changes before i was maintainer of glibc however, that'd account for most libraries, but not all ... you still need to leave the threading library unstripped regardless (libthread_db-1.0.so) i'll drop the strip masking for the other libraries in glibc-2.6 and see who complains
was fixed a while ago
