write/coff: add Writer

[philipc]

No description provided.

[simonbuchan]

So I ported over to this in:

https://github.com/simonbuchan/rustc_codegen_cranelift/tree/raw_dylib_object_write

That also now includes a test based on the enum-windows test I've been using, so you should be able to repro with ./y.sh test

I had to add some writer.write_align(4) before the section raw data, but I'm not sure if there's anything much you can do there if writer.write_section() can't be given the data nicely. Perhaps a writer.start_section() as an alias to writer.write_align(4)?

Incidentally regarding that align the docs for PointerToRawData says that:

For object files, the value should be aligned on a 4-byte boundary for best performance.

But if this will also be used for image files:

For executable images, this must be a multiple of FileAlignment from the optional header.

Not sure if that's an issue?

I should note that from memory, the MSVC linker pads the section raw data length to 2-bytes, but it seems fine without that.

[philipc]

Perhaps a writer.start_section() as an alias to writer.write_align(4)?

Sure, although I might call it writer.write_section_align().

For executable images, this must be a multiple of FileAlignment from the optional header.

The existing write::pe::Writer already handles that. I haven't tried to share code between the PE and COFF writers.

I should note that from memory, the MSVC linker pads the section raw data length to 2-bytes, but it seems fine without that.

Is that padding included in the size_of_raw_data field of the section header? Or is it just alignment padding before relocations or the symbol table?

[simonbuchan]

I'd need to double check what dumpbin said, but I'm pretty sure it was included in the length. The docs for SizeOfRawData do mention:

Because the SizeOfRawData field is rounded but the VirtualSize field is not, it is possible for SizeOfRawData to be greater than VirtualSize as well.

But it only mentions a rounding value for images.

The only time you could tell from the sections in these objects is the dllname, so entirely possible it's specific to them.

It's easy enough to handle on the use-side either way, so I wouldn't worry about it (my existing code ignored it, after all), I just wanted to mention it in case it causes something weird for someone later.