[patch] support reading DATA members in ILF format DLL import libraries

[Nathaniel Smith <njs at pobox dot com>]

[Also posted here:
https://sourceware.org/bugzilla/show_bug.cgi?id=19541, but Kai Tietz
suggested I should send to the mailing list]

Hi all,

On Windows, there are two formats for "import libraries" commonly in
use: the format generated by dlltool and commonly used with mingw-w64
toolchains, which is an ar archive of COFF objects (conventionally
named like "libpython27.a"), and the format generated and commonly
used by MSVC toolchains, which is an ar archive of "ILF" objects (and
conventionally named like "python27.lib").

Either way, the purpose of such files is to provide DLL imports. DLL
imports come in two main flavors. There are "code" symbols, which
refer to functions, and which require (a) a relocation symbol named
__imp__foo, and (b) a static symbol named _foo that just acts as a
trampoline, jumping to __imp__foo. And then there are "data" symbols,
which refer to things like global variables exported from a DLL, and
only require a __imp__foo symbol, with no trampoline symbol. In the
ILF format these two symbol types are represented identically, except
that there is a flag value labeling each import symbol as either
IMPORT_CODE or IMPORT_DATA.

Unfortunately, binutils's ILF-reading code currently only supports
IMPORT_CODE symbols. Any symbols with the IMPORT_DATA flag set are
completely skipped over, as if they didn't exist, leading to linker
errors. (And rather mysterious ones, because objdump also lies and
claims that the symbol really doesn't exist...)

One place where this causes problems is when attempting to use
binutils to link programs against the python C API, because
python27.dll makes extensive use of DATA symbols. But really it would
be nice to support these in general, because it should be simple to do
and it would be nice if we didn't have to jump through hoops to use
import libraries on Windows. In addition, mingw-w64 is looking to
transition to a new 'genlib' tool for generating import libraries, and
genlib also generates ILF-format libraries.

The attached patch provides a simple fix. Right now all the code for
emitting import symbol information from ILF files is hidden behind
switch { case IMPORT_CODE: ...}; my patch just takes the functionality
that should be common between code and data symbols and moves it
outside of the switch statement so that it is executed
unconditionally. The function-specific trampoline generation code
remains inside the switch statement, and if we see anything besides
IMPORT_CODE or IMPORT_DATA then we abort(), so this should be safe.

I haven't signed FSF paperwork -- not sure whether it's needed for a
change this small. (Literally all it does is move some existing lines
of code up or down a few lines.) But I can if needed.

Let me know if you have any questions or I can help with anything,
-n

-- 
Nathaniel J. Smith -- https://vorpus.org

Attachment: ILF-read-DATA-symbols.diff
Description: Text document