Unknown file magic for MSVC object files with magic 00, 00, ff, ff

[jayvdb]

indygreg/PyOxidizer#183 is doing symbol renaming to avoid a clash, and it works fine on Linux, fails to link on macOS (despite adding some extra symbol mangling), but on Windows I hit "Unknown file magic". It would be helpful if there was a way to get the magic byte sequence out in order to see what it is.

[philipc]

Hex dump the file, it's the first few bytes. There error is from here, you can see which magic byte sequences it supports.

[philipc]

Also, just to manage expectations, the objcopy code probably isn't production ready. If you can get it working that's great, but don't expect too much. So far it's only been used on a limited number of rust binaries.

[jayvdb]

It has worked quite well for me on Linux, on quite a large number of Python built extensions I needed renaming of symbols.

Unless there is a rust alternative I should be using instead, I'd prefer to preserve rather than using binutils binaries and whatever the equiv would be with Windows. PyOxidizer is also bleeding edge, so it is a good fit ;-)

[jayvdb]

I've added magic hex printing to my PR.

Also I disabled the object mangling, and instead copied the existing prefix of the symbol, and now macOS is linking correctly with the new sym name.

[philipc]

I'm not familiar with the magic 00, 00, ff, ff, and it doesn't appear to match any COFF machines. Are you sure this is an object file? Can you find out what sort of file this is, or attach it here?

[jayvdb]

It is on the Windows Azure "vs2015-win2012r2" workers on that PR, and I dont have Windows locally, and this needs real MSVC to reproduce, so I can only get more info by adding debugging to the code. I am attempting to get results from other more recent Windows images to see if it occurs on them also.

It wouldnt surprise me if this is a Windows intermediate file format, but they are extracted out of the source trees where they were built and linked together using CL, so I am ruling out them being a file which only refers to a real object file.

Also note that my hex printing logic might be wrong.(actually this is highly likely atm ;-)

[jayvdb]

Expanded it to be 00, 00, ff, ff, 01, 00, 64, 86, 63, 7b, d6, 5d and it now looks more like COFFs magic with 64, 86 appearing.

[jayvdb]

fwiw, these objects are described in broad terms at https://docs.python.org/3/extending/windows.html

The source file is https://github.com/simplejson/simplejson/blob/master/simplejson/_speedups.c

The compile line is

C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\x86_amd64\cl.exe /c /nologo /Ox /W3 /GL /DNDEBUG /MD -DPy_BUILD_CORE_BUILTIN=1 -ID:\pyapp\build\target\x86_64-pc-windows-msvc\debug\pyoxidizer\python.86a3260edabe\python\install\include -ID:\pyapp\build\target\x86_64-pc-windows-msvc\debug\pyoxidizer\python.86a3260edabe\python\install\include "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE" "-IC:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\ATLMFC\INCLUDE" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\ucrt" "-IC:\Program Files (x86)\Windows Kits\NETFXSDK\4.6.1\include\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\shared" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\um" "-IC:\Program Files (x86)\Windows Kits\10\include\10.0.14393.0\winrt" /Tcsimplejson/_speedups.c /Fobuild\temp.win-amd64-3.7\Release\simplejson/_speedups.obj

I've check that the output of that command (_speedups.obj) has the same magic that I am seeing in the final output.

OTOH, I have check the .obj files in https://github.com/indygreg/python-build-standalone/releases/download/20191025/cpython-3.7.5-windows-amd64-20191025T0540.tar.zst , and they have a conventional magic.

[jayvdb]

Cause of the parse problem raised upstream as m4b/goblin#194

[philipc]

Looking at this again, those bytes look like ANON_OBJECT_HEADER, (e.g. see https://stackoverflow.com/questions/32639518/how-to-determine-the-major-compiler-version-from-obj-files-compiled-with-gl). This is something we might be able to handle. I'll add the header definitions for this as part of #167, and I'll look into it further after that.

[assarbad]

@philipc The marker described above, IMAGE_FILE_MACHINE_UNKNOWN (== 0) for Sig1 and IMPORT_OBJECT_HDR_SIG2 (meaning "0xFFFF sections"), is sort of documented as being used for those "object files" which comprise import libraries.

IMPORT_OBJECT_HEADER is the relevant struct from ntimage.h/winnt.h.

Also see this