From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.0.3 (X11; Linux i686; U;) Gecko/20020205 Description of problem: When compiling a program with gcc -g the resulting ELF objects have a .stab and a .comment section of type PROGBITS. The problem is that ELF sections of type PROGBITS are loaded into memory by the runtime linker but the .comment and .stab section have no useful purpose in that context. Given that .stab sections can be really huge, this problem can manifest itself as slower fork speed. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1.Build yourself a window manager with -g 2.Run that WM 3.Have the WM start a gnome-terminal or something, notice that it's slow. 4. Copy you WM, strip WM, run that and repeat step 3, notice the difference. Having trouble seeing the difference? Try the experiment on an -rmap kernel from Rik van Riel where fork()ing is extra slow (particular rmap12d). Additional info:
That's correct. SHT_PROGBITS means the section contains data not covered by ELF specification (as opposed to SHT_NOBITS, which contains just zeros, or SHT_SYMTAB etc. which have special meaning in ELF). Section type really has no influence on whether the section is loaded or not. That's what SHF_ALLOC in sh_flags is for. .stab section is normally with sh_flags 0, like: [26] .stab PROGBITS 00000000 136180 33a3bc 0c 27 0 4 but application can screw this up for itself, e.g. by using asm (".section .stab, \"a\", @progbits; .previous"); or similar in its source. Don't know about which WM you're talking about, but I'd suggest you to readelf -a on its binary and check these things up if you have any doubts.
my bad. you're right. more investigation required. thanks (BTW, the WM is blackbox)
Once you have more info, please reopen.