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
Version-Release number of selected component (if applicable):
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).
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:
 .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.
(BTW, the WM is blackbox)
Once you have more info, please reopen.