This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

PE/COFF propper _raw_size


The PE/COFF format requires the section header field s_size to contain a
page aligned size.  The s_paddr field contains the virtual in memory size.
This virtual size may be smaller because of page alignment padding, or
larger because of zero filled extension.

Since the bfd section field _raw_size is filled directly from the s_size
field, it currently contains the padded size.  I believe this poses two
problems.

1.) PE unaware, "generic" applications that use bfd's _raw_size as the
actual size of section data can be confused by the extra zero padding.

2.) During linking, I think this causes the padding to be maintained
when sections are concatenated rather than just padded at the end.

I have posed a solution to this previously here:
http://sources.redhat.com/ml/binutils/2003-02/msg00341.html

but since it just aligned the file offset like other COFF targets and not
the s_size field, it violates the PE spec.  I did not receive any comments
on that proposal.

A better solution for PE, I think, would be to populate _raw_size with the
smaller of s_paddr and s_size.  I believe this would solve the two issues
presented above.  On output, due to current code, s_paddr would still get the
virtual in memory size and s_paddr would get the page aligned size.

I believe the correct place to do this is in coffgen.c
(make_a_section_from_file), but I hate to introduce a COFF_WITH_PE ifdef
there.  (Incidentally, if bfd is supposed to support a super-bfd that
works with all formats, how can we have ifdef code at all?)  Another
alternative would be to post process the sections in peicode.h
(pe_bfd_object_p).

I am still trying to get my feet wet in this mass of code.  Just trying
to figure out which code is actually used for my particular target
seems very challenging.  So, I may be off base on the proposed
locations for this change.  Any comments on the best place to
do this, or on the proposed method will be greatly appreciated.  Thanks.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]