Home Original page

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

Kai Tietz ktietz70@googlemail.com
Mon Feb 1 10:48:00 GMT 2016 
Hi Nick,

IMO this patch fixes a pretty obvious lack of functionality about
pe-coff anon-object stuff.  Not sure if for it FSF-paperwork is
necessary, as indeed - as Nathaniel explained - he just moved
code-lines.  That's your decision ... So for me patch works fine and
doesn't shows any new regressions for pe-coff.

Cheers,
Kai

2016-02-01 7:25 GMT+01:00 Nathaniel Smith <njs@pobox.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
More information about the Binutils mailing list