Page MenuHomePhabricator

[llvm-objcopy] [COFF] Fix writing object files without symbols/string table
ClosedPublic

Authored by mstorsjo on Jan 11 2019, 1:49 AM.

Details

Summary

Previously, this was broken - by setting PointerToSymbolTable to zero but still actually writing the string table length, the object file header was corrupted.

Splitting out this independent fix from D56481.

Diff Detail

Event Timeline

mstorsjo created this revision.Jan 11 2019, 1:49 AM

I'm not quite sure I follow why this only affects executable files? Why is this an issue in PE but not plain COFF?

I'm not quite sure I follow why this only affects executable files? Why is this an issue in PE but not plain COFF?

Initially I tried to make the output of llvm-objcopy as close as possible to the output from various tools (llvm-mc and MSVC), and to achieve this, I only skipped including the symbol/string table in executables, while keeping it present in object files.

I know that exactly matching the output of another tool shouldn't be a goal in itself, but I don't know if there are tools out there that would flat out reject an object file with an omitted symbol/string table, as opposed to an empty symbol/string table. So keeping this distinction probably is safer.

I'm not quite sure I follow why this only affects executable files? Why is this an issue in PE but not plain COFF?

Initially I tried to make the output of llvm-objcopy as close as possible to the output from various tools (llvm-mc and MSVC), and to achieve this, I only skipped including the symbol/string table in executables, while keeping it present in object files.

I know that exactly matching the output of another tool shouldn't be a goal in itself, but I don't know if there are tools out there that would flat out reject an object file with an omitted symbol/string table, as opposed to an empty symbol/string table. So keeping this distinction probably is safer.

So the behaviour change is that for objects, the object now has a pointer to the symbol table, which it didn't before. I think I get it now. The problem is the writeSymbolStringTables function, and you want that to always write a size for object files, even if the table is empty, right?

I'm not quite sure I follow why this only affects executable files? Why is this an issue in PE but not plain COFF?

Initially I tried to make the output of llvm-objcopy as close as possible to the output from various tools (llvm-mc and MSVC), and to achieve this, I only skipped including the symbol/string table in executables, while keeping it present in object files.

I know that exactly matching the output of another tool shouldn't be a goal in itself, but I don't know if there are tools out there that would flat out reject an object file with an omitted symbol/string table, as opposed to an empty symbol/string table. So keeping this distinction probably is safer.

So the behaviour change is that for objects, the object now has a pointer to the symbol table, which it didn't before. I think I get it now. The problem is the writeSymbolStringTables function, and you want that to always write a size for object files, even if the table is empty, right?

Correct. Previously the pointer to the symbol table was zero, so the string table length (which follows directly after the symbol table) was written at offset 0 in the file, clobbering the header.

This revision is now accepted and ready to land.Jan 11 2019, 5:31 AM
This revision was automatically updated to reflect the committed changes.