Bug 59754 - ld creates .stab and .comment sections as PROGBITS
Summary: ld creates .stab and .comment sections as PROGBITS
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2002-02-12 19:18 UTC by Georg Nikodym
Modified: 2007-04-18 16:40 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-02-14 01:05:02 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Georg Nikodym 2002-02-12 19:18:23 UTC
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:

Comment 1 Jakub Jelinek 2002-02-13 12:23:33 UTC
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.

Comment 2 Georg Nikodym 2002-02-14 01:04:57 UTC
my bad. you're right.  more investigation required.
thanks

(BTW, the WM is blackbox)


Comment 3 Jakub Jelinek 2002-02-14 11:29:52 UTC
Once you have more info, please reopen.


Note You need to log in before you can comment on or make changes to this bug.