This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
[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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |