gld-2.9.1 bug report

[lchu@xylan.com (Larry Chu)]

I reported a problem of using the version 2.9.1 gnu-gld in late October.
The problem was as follows:

>  Larry Chu wrote:
>
>> I downloaded the GNU gcc-2.8.1 and binutils-2.9.1. I sucessfully built a
>> cross compiler for sparc Sun solaris host and VxWorks target.
>>
>> I tested the new compiler and linker by compiling a group of source
>> files.  The compiler works fine. It built all the object files. The
>> object file sizes are comparable with the ones compiled by our current
>> version of gcc (version cygnus 2.2.3.1).
>>
>> However, after the object files were linked into an executable image,
>> the file size of the resulting image became enormous (46 meg) compared
>> with the one linked by our current linker (version 1.97.1) which
>> produced only a 1.5 to 1.9 meg file. An increase of 24 times the
>> original size!
>>
>> In addition, when I use 'ls -l' to display the file information, it
>> shows 46 meg of file size. But if I use 'ls -s' command, the block size
>> of the file is shown as 3290 blocks which corresponds to 1.68 meg. The
>> block size is very close to that of the old one.
>>
>> I would like to know what causes the difference in the sizes and how can
>> I use the new linker to produce the same smaller size image.
>>

After an intensive research on the program code of the linker, I located
the problem area.

It is in the file `aoutx.h' under the `binutils-2.9.1/bfd' directory. There
is a subroutine `adjust_o_magic' which is used by gld to calculate the
sizes of the padding bytes for the text, data, and bss sections.

For the bss section, if the VMA is set by the user, the pad is calculated
as follows:

   pad = obj_bssec (abfd)->vma - vma; (vma holds the VMA of text plus
                                       sizes of text and data)
   
Then the pad is added to the file position, pos, and the file pointer is 
seeked to that position. The next record written to the output file will
start from there.

The problem is that if the user sets the VMAs of both text and bss
sections, the area between the two VMAs if not written already, will be
filled with zeros and written to the file. Therefore the file size of the
resulting executable image is determined by the VMAs but not the real
contents of the three sections.

We commented out the pad statement and re-compiled the linker. After using
the new linker, we obtained a file with correct size and the problem is
considered solved.

Hope this information is helpful to those people who are having the same
problem.


Regards,

Larry Chu (lchu@xylan.com)
_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.