outcoff: set the "virtual size field" to zero (BR 1351586)
commit10ba8490ce2ea05b4ccf5d8f69ac703e1e3b437f
authorH. Peter Anvin <hpa@zytor.com>
Tue, 25 Sep 2007 00:02:07 +0000 (24 17:02 -0700)
committerH. Peter Anvin <hpa@zytor.com>
Tue, 25 Sep 2007 00:02:41 +0000 (24 17:02 -0700)
treea8e67ad4d3d2814263a7a8de99f35ebf5d72de4f
parent415c7ced1dcdecf49966037fb38210634fc49008
outcoff: set the "virtual size field" to zero (BR 1351586)

Per SF bug report 1351586:

The COFF spec suggests that the "Virtual Size" field (which
immediately follows the name field inside a section header) be set to
0 for an object file.

By contrast (as documented in comment #4 at the beginning of its
outcoff.c file) NASM sets it to a particular non-0 value.

MASM 6.15 matches NASM for both 16- and 32-bit object files,
i.e. emits non-0 values.

MASM 8 (from VS 2005 Beta) matches the COFF spec for 64-bit object
files, i.e. emits 0.

GAS matches the COFF spec for 32-bit object files (MinGW or Cygwin),
i.e. also emits 0.

Older versions of GNU ld seem to honor said "Virtual Size" field
whereas newer versions do not.  As a result those older versions
generate "bloated" image files.

Since the COFF spec and the real world seem to disagree for this case,
it might make sense to add a method for selecting between the two to
NASM.

Date: 2005-11-28 15:39
Sender: nasm64developer
Logged In: YES
user_id=804543

MASM 8 (from VS 2005 Beta) also matches the COFF spec for 16- and
32-bit object files, i.e. emits 0.

That said, NASM should always emit 0 too. Therefore I am turning this
from a support request into a bug.
output/outcoff.c