[Bug ld/21076] New: (cygwin) Output DLL import lookup/address tables are incorrect

[afranchuk at lgsinnovations dot com]

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

            Bug ID: 21076
           Summary: (cygwin) Output DLL import lookup/address tables are
                    incorrect
           Product: binutils
           Version: 2.27
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: afranchuk at lgsinnovations dot com
  Target Milestone: ---

I have a large chunk of code (some of which is large enough that the PE big-obj
format must be used) that is being linked into a DLL by binutils-2.27 in a
Cygwin 64-bit environment. I built the binutils myself, as the binutils
currently distributed by Cygwin is too old and does not support the big-obj
format.

The linking executes and completes okay, however the DLL fails to be loaded,
with a missing dependency that cannot be resolved. Looking at the import tables
using Dependency Walker (or just objdump -p), I see that a dependency that is
marked as being in one DLL is "leaking" into being marked as needed in another.
In other words, the import table says that a symbol "myfunc" is in BOTH "a.dll"
and "b.dll", when it is supposed to only be in "b.dll". I used hexdump to view
the raw linked DLL and, using the PE specification as a guide, found that the
empty (NULL) entry that is supposed to signify the end of the import
lookup/address table is being overwritten for "a.dll". So the dependencies for
"b.dll" (in this example, a symbol called "myfunc") are overwritting the NULL
terminating entry of the previous DLL ("a.dll"), so that from the parsing of
the PE format "myfunc" appears to be in the lookup table and address table for
"a.dll", and then also (and correctly) in that of "b.dll".

I cannot share the reproducing code, and this is the first time this has
occurred. I have linked many other large code bases into DLLs and executables
without this occurring, and other DLL references in the import lookup table of
the DLL I'm linking do not exhibit this issue. This issue IS in both the import
lookup table (.idata$4) and the import address table (.idata$5).

I have spent a good few hours already trying to find the source of the bug in
the ld/bfd source code, but haven't found it yet (part of those hours was
getting familiar with the program flow, though).

Any help would be greatly appreciated!

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