Re: Shared library size anomaly

[Bryce McKinlay <bryce at mckinlay dot net dot nz>]

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.