Bug 11033 - gold creates twice time bigger binaries, sometimes
Summary: gold creates twice time bigger binaries, sometimes
Status: RESOLVED WORKSFORME
Alias: None
Product: binutils
Classification: Unclassified
Component: gold (show other bugs)
Version: 2.21
: P2 normal
Target Milestone: ---
Assignee: Ian Lance Taylor
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-11-30 15:20 UTC by Michal Nowak
Modified: 2011-07-09 00:25 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
ld's pvfnoise (5.54 KB, application/octet-stream)
2009-11-30 15:21 UTC, Michal Nowak
Details
gold's pvfnoise (13.26 KB, application/octet-stream)
2009-11-30 15:21 UTC, Michal Nowak
Details
ld's readelf -a (3.31 KB, text/plain)
2009-11-30 15:22 UTC, Michal Nowak
Details
gold's readelf -a (3.96 KB, text/plain)
2009-11-30 15:22 UTC, Michal Nowak
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Michal Nowak 2009-11-30 15:20:16 UTC
GNU gold (version 2.20.51-0.20091130.7.fc12 20091130) 1.9
gcc (GCC) 4.4.2 20091027 (Red Hat 4.4.2-7)

Running trunk 20091130 at x86_64. When I rebuild & link mgetty package from
Fedora with ld and gold I get twice that large binaries for gold (both stripped).

E.g.

-rwxr-xr-x. 1 newman newman 34K 2009-11-30 15:39 gold/pvfnoise
-rwxr-xr-x. 1 newman newman 13K 2009-11-30 15:37 ld/pvfnoise

When diffing readelf outputs I can see that this junk is in gold/pvfnoise but
not in ld/pvfnoise:

Relocation section '.rela.plt' at offset 0xc68 contains 55 entries:         
  Offset          Info           Type           Sym. Value    Sym. Name + Ad
[...]
0000006071d8  000100000007 R_X86_64_JUMP_SLO 0000000000000000 fileno + 0    
0000006071e0  000200000007 R_X86_64_JUMP_SLO 0000000000000000 close + 0     
0000006071e8  000300000007 R_X86_64_JUMP_SLO 0000000000000000 __isoc99_fscan
0000006071f0  000400000007 R_X86_64_JUMP_SLO 0000000000000000 __fprintf_chk 
0000006071f8  000600000007 R_X86_64_JUMP_SLO 0000000000000000 __isoc99_sscan
000000607200  000700000007 R_X86_64_JUMP_SLO 0000000000000000 openlog + 0   
000000607208  000800000007 R_X86_64_JUMP_SLO 0000000000000000 exit + 0      
000000607210  000900000007 R_X86_64_JUMP_SLO 0000000000000000 __assert_fail 
000000607218  000a00000007 R_X86_64_JUMP_SLO 0000000000000000 getopt + 0    
000000607220  000b00000007 R_X86_64_JUMP_SLO 0000000000000000 read + 0      
000000607228  000c00000007 R_X86_64_JUMP_SLO 0000000000000000 strncmp + 0   
000000607230  000d00000007 R_X86_64_JUMP_SLO 0000000000000000 malloc + 0    
000000607238  000e00000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_m
000000607240  000f00000007 R_X86_64_JUMP_SLO 0000000000000000 unlink + 0    
000000607248  001000000007 R_X86_64_JUMP_SLO 0000000000000000 getpid + 0    
000000607250  001100000007 R_X86_64_JUMP_SLO 0000000000000000 fgets + 0     
000000607258  001200000007 R_X86_64_JUMP_SLO 0000000000000000 fputc + 0     
000000607260  001300000007 R_X86_64_JUMP_SLO 0000000000000000 free + 0      
000000607268  001400000007 R_X86_64_JUMP_SLO 0000000000000000 _IO_getc + 0  
[...]
Comment 1 Michal Nowak 2009-11-30 15:21:01 UTC
Created attachment 4425 [details]
ld's pvfnoise
Comment 2 Michal Nowak 2009-11-30 15:21:33 UTC
Created attachment 4426 [details]
gold's pvfnoise
Comment 3 Michal Nowak 2009-11-30 15:22:02 UTC
Created attachment 4427 [details]
ld's readelf -a
Comment 4 Michal Nowak 2009-11-30 15:22:15 UTC
Created attachment 4428 [details]
gold's readelf -a
Comment 5 Ian Lance Taylor 2010-01-07 18:56:52 UTC
These two programs just look different, and it's hard for me to believe that this 
is due to a difference between GNU ld and gold.  For example, the gold binary has 
calls to fgets where the GNU ld binary does not.  The gold binary has several 
more calls to __stack_chk_fail.  Using gold should not cause changes of that 
sort.

If you still see this problem, can you attach the complete set of input files and 
the link command that you are using?  Thanks.
Comment 6 Ian Lance Taylor 2011-07-09 00:25:44 UTC
Closing due to lack of response.  Please reopen with additional information if this is still a problem.  Thanks.