[prev in list] [next in list] [prev in thread] [next in thread]
List: binutils
Subject: Re: Shared library size anomaly
From: Bryce McKinlay <bryce () mckinlay ! net ! nz>
Date: 2003-09-26 7:24:37
Message-ID: 7C6FDD94-EFF2-11D7-BCD7-003065F97F7C () mckinlay ! net ! nz
[Download RAW message or body]
On Thursday, Sep 25, 2003, at 21:55 Pacific/Auckland, Andreas Schwab
wrote:
> Bryce McKinlay <bryce@mckinlay.net.nz> writes:
>
>> Here's something weird that I noticed while messing around with the
>> merge
>> patch. A libgcj.so created by:
>>
>> $ ld -r -o temp.o (all object files...)
>> $ gcj --shared temp.o -o libgcj.so
>>
>> is some 400K smaller than one created with:
>>
>> $ gcj --shared -o libgcj.so (all object files...)
>>
>> Each of the libraries works fine. Examining with objdump revealed that
>> almost all the sections had slightly different sizes, however .rodata
>> seems to be accounting for most of the discrepancy:
>>
>> - 11 .rodata 000a0599 005c6440 005c6440 005c6440 2**5
>> + 11 .rodata 000f776b 005ca1e0 005ca1e0 005ca1e0 2**5
>> CONTENTS, ALLOC, LOAD, READONLY, DATA
>>
>> Any clues what would cause this? Could this be a constant merging bug?
>
> Try examining the linker map (generated by passing -Map=file to the
> linker).
Thanks Andreas. The size difference seems to observable with any number
(2 or more) of .o files from the libgcj build that contain a mergable
utf8 constants, so I cut the test case down to 2 files and took a look
at the linker maps produced.
This caught my eye. For "ld -shared ... -o test.so", there are 2 of
each of the utf8.x sections, eg:
.rodata.jutf8.18
0x000036b2 0x48 LocaleInformation_ko_KR.o
.rodata.jutf8.18
0x0000327e 0x5a LocaleInformation_kl_GL.o
For "ld -r ... -o test.o; ld -shared test.o -o test.so":
.rodata.jutf8.18
0x0000327e 0x5a temp.o
0xa2 (size before relaxing)
Note that the total size of the two utf8.18 sections emitted by -shared
adds up to the "size before relaxing" size produced in the second case.
Sure enough, looking at the .s source these two files contain mergable
utf8's in the jutf8.18 section - so for some reason, in the first case,
these do not get merged.
I did some debugging of merge.c and couldn't see any obvious problems.
The same number of entries get added to the hashtable in each case, and
sec_merge_emit() emits the same number of strings in each case. Perhaps
it is is possible the merging is working correctly, but the linker
isn't taking this into account when allocating space for each instance
of a given section name?
(BTW this problem is not related to the merge speedup patch, I see the
same behavior with an old linker).
Regards
Bryce.
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic