Re: PE/COFF _raw_size 2003-04-15 BFD patch breaks my project

[Nick Clifton <nickc at redhat dot com>]

Hi Aaron,

> After doing some misc. upgrades, I noticed my project suddenly and
> inexplicably failed to link.  I traced it to this patch: 
> 2003-04-15  Brian Ford  <ford@vss.fsi.com>
>
>         * peicode.h (coff_swap_scnhdr_in): If a section holds
>         uninitialized data and is from an object file or from an
>         executable image that has not initialized the s_size field, or if
>         the physical size is padded, use the virtual size (stored in
>         s_paddr) instead.
>
> Thread: http://sources.redhat.com/ml/binutils/2003-04/msg00272.html
>
> Specifically, one of the object files (generated by a Microsoft
> compiler) contains a .text section with a VirtualSize 0x40 but a
> SizeOfRawData 0x676.  There are relocations into this section with
> addresses >0x40.  Since this patch causes _raw_size to be set to
> VirtualSize instead of SizeOfRawData, BFD generates an error at
> relocation time and the link fails: 
> ld: myobj.obj: bad reloc address 0x50 in section `.text'
> ld: final link failed: Invalid operation
>
> In all honesty, I do not know why the MS compiler generates this
> kind of object.  There is nothing about it in "Microsoft Portable
> Executable and Common Object File Format Specification Revision 6.0
> - February 1999," at any rate.  (It does not mention the case where
> SizeOfRawData > VirtualSize.) 
>
> However, since this object is part of a library in a Microsoft SDK,
> which is probably produced by a new version of Microsoft's compiler,
> it seems reasonable to me that the 2003-04-15 patch should be
> altered or reversed. 
>
> In any case, lieing about the actual size of the section to all of
> BFD does not seem like a good thing, and may cause problems in
> addition to those that I am having.  Perhaps a better way to
> implement Brian Ford's patch might be to compare these two section
> sizes locally to the parts of BFD that might take advantage from
> doing so, eg when doing section merging. 
>
> Any comments?  If this patch is not critical to maintaining
> functionality somewhere, I'd recommend it be reversed until a better
> solution is found. 

Well Brian was trying to fix a real problem:

  http://sources.redhat.com/ml/binutils/2003-04/msg00240.html

So just reverting the patch will probably not help.

Which target are you using ?  You may find that defining
COFF_NO_HACK_SCNHDR_SIZE in a similar way to bfd/pe-mips.c will help
your target.

Alternatively what may be needed is a better heuristic to determine
why the raw size has been set to larger than the virtual size.
Brian's patch was trying to overcome issues with padding and section
alignment.  Maybe the code could check to see if the difference
between two sizes does amount to an alignment padding operation.  If
not, then the sizes could be left alone.

Cheers
        Nick