https://sourceware.org/bugzilla/show_bug.cgi?id=19540
Bug ID: 19540 Summary: Format reader for ILF format (used by MSVC-generated import libraries) does not properly handle data imports Product: binutils Version: unspecified Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: njs at pobox dot com Target Milestone: --- 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 __imp___foo relocation symbol, and (b) _foo trampoline that just jumps 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 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. 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. I've attached a patch that in theory ought to fix this. Basically, 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 parts that are common to IMPORT_CODE and IMPORT_DATA and moves them out of the switch statement so that they are 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. The patch compiles, and using it to manually link a simple test program against python27.lib produces correct-looking output (i.e., a binary is successfully produced, and running objdump on it shows that it has a correct-looking import table that successfully references DATA symbols in python27.dll). Unfortunately though I don't have a great way to test this directly (no handy Windows system, and no convenient way to build a whole toolchain including my patched ld), and someone else reported that when they did all that then the compile seemed to work but the resulting binary segfaulted. (Possibly due to unrelated issues though, who knows.) So, I'm posting this here in hopes that either someone who knows what they're doing will look at it and think "well, this is obviously correct", or else think "well, this is obviously broken, you need to do _____" :-) Some discussion where we found this bug: https://github.com/mingwpy/mingwpy.github.io/issues/31#issuecomment-175334085 -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils