[PATCH] D73502: [BinaryFormat] Limit COFF file detection with unknown machine type

[Sam Clegg via Phabricator via llvm-commits]

sbc100 added a comment.

In D73502#1847393 <https://reviews.llvm.org/D73502#1847393>, @efriedma wrote:

> llvm::identify_magic is not really a general-purpose file identification routine; it's specifically designed to sniff out the format of files which are interesting to LLVM tools, and it doesn't try very hard to figure out whether the input is valid.  If it's returning file_magic::unknown, probably something has gone wrong elsewhere.  That said, it would be nice to use more than two bytes to make a positive identification, if there's some other reliable indicator for a COFF object.


But tools like llvm-nm do end up using identify_magic to decide if they should decode an object.   Running llvm-nm on ar archives is supposed to be robust against non-object files being in the archive I believe.

> Are PE object files with IMAGE_FILE_MACHINE_UNKNOWN actually something that shows up in practice (besides the special case of "\0\0\xFF\xFF")?  What would such a file contain?  Can any LLVM tools do anything interesting with it?

It seem very unlikely that there are any uses for such an object.

> If we're going to try to sniff out whether the COFF header is valid, should we do it for all coff_object files?

Yes,  I thought that was what this change was doing but maybe it should happen elsewhere too.

> Is it reasonable to assume all COFF object files have at least one section?  It's sort of degenerate, but it's possible to construct an empty object file.

I think it is reasonable, although this change did uncover a test file that creates and emtpy object file from yaml.   Note that in my experiments it is *not* possible create such an empty object file using clang or llvm tools.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73502/new/

https://reviews.llvm.org/D73502