[Bug ld/22178] New: mingw64 x86 idata sort issue when dll import library does not import a PE file name ending with .dll

[dougsemler at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22178

            Bug ID: 22178
           Summary: mingw64 x86 idata sort issue when dll import library
                    does not import a PE file name ending with .dll
           Product: binutils
           Version: 2.28
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: dougsemler at gmail dot com
  Target Milestone: ---

When using an import library generated with MSVC for a dll, the import library
archive contains member names that are the same for all import table objects in
the archive.  When the import library is specifying imports against a DLL file
that ends with 'dll', the linker adds to the archive names a .a to the
percieved "head", a .c to the "tail", and .b to anything else that contains an
external symbol.  This means that the sorting that is done puts the IAT in the
correct order since it outputs the symbols as HEAD imports TAIL.  However, if
the member name does NOT end in dll, the sort does not occur. The IAT is sorted
in the order that ld sees the imports, causing the head and tail locations to
end up being back-to-back.  The comment in ld/emultempl/pe.em explains that
this is to skip over potential static objects that may also be in the import
library.  The code then specifies the comparison if (import_lib &&
membername_endswith("dll")) then treat it as an import library with sort
suffixes added.  However, since PE targets can be named pretty much anything, a
more appropriate check to avoid importing static objects is probably to be
stricter and check if (import_lib && !(membername_endswith(".o") ||
membername_endswith(".obj")) so that import libraries that specify imports for
files other-than-dlls are correctly sorted.

This does not apply if the link is explicitly applied against the DLL itself
and the import table is built implicitly by the linker.  This also does not
apply if the import library was generated from a gcc build of the DLL, since
the archive members are given correctly sorted .o filenames in that case and
the pe link code skips the addition (since they don't end in .dll).

Note a separate issue is the fact that attempting to directly link against a
.EXE PE file that declares exports does not work since the implicit generation
of import libraries is not performed against files with an EXE rather than DLL
header.

-- 
You are receiving this mail because:
You are on the CC list for the bug.