Created attachment 8420 [details]
testcase

was writing a tool that builds a dll import library (.a) that shows GCC mangled C++ symbols to GCC, but the DLL import table names are MSVC mangled C++ names. I didn't want to use runtime GetProcAddress to call MSVC C++ code for startup speed/binary size reasons (see https://github.com/wine-mirror/wine/blob/master/dlls/msvcp90/msvcp_main.c for an example of calling MSVC C++ from GCC). Since the MSVC C++ symbols aren't methods and have no this arg, and are cdecl calling convention, it works. 

While writing that tool, I discovered that there will be multiple "foo.dll" strings in the GCC produced DLL from multiple IMAGE_IMPORT_DESCRIPTOR structs to foo.dll. Each IMAGE_IMPORT_DESCRIPTOR was coming from one .a where the IMAGE_IMPORT_DESCRIPTOR had a different symbol name based on the output file name to "-l" option of dlltool. I figured out that the IMAGE_IMPORT_DESCRIPTOR can be de-duped if they all have the same symbol name. This worked fine on ld 2.19 and ld 2.17. When trying the code on newer lds I get
---------------------------------------------
ld.exe: final link failed: File truncated
collect2: ld returned 1 exit status
---------------------------------------------

The idea of merging IMAGE_IMPORT_DESCRIPTOR is shown in ldbug.zip.

gcc version 4.9.2 (i686-posix-sjlj, built by strawberryperl.com project)
GNU ld (GNU Binutils) 2.25
GNU dlltool (GNU Binutils) 2.25


ldbug failed at link time, no main.exe generated

C:\Documents and Settings\Administrator\Desktop\ldbug>gcc -g -O2 -o main.exe ma
in.o user32.a -lmingw32 -lgcc -lmingwex -lmsvcrt -lkernel32
C:/sp3222/c/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/b
in/ld.exe: final link failed: File truncated
collect2.exe: error: ld returned 1 exit status

C:\Documents and Settings\Administrator\Desktop\ldbug>

Going a little bit older toolchain at 2.22

gcc version 4.6.3 (gcc-4.6.3 release with patches [build 20120411 by perlmingw.s
f.net])
GNU ld (GNU Binutils) 2.22.52.20120310
GNU dlltool (GNU Binutils) 2.22.52.20120310


ldbug failed at link time, no main.exe generated

C:\Documents and Settings\Administrator\Desktop\ldbug>gcc -g -O2 -o main.exe ma
in.o user32.a -lmingw32 -lgcc -lmingwex -lmsvcrt -lkernel32
c:/sp3216/c/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/b
in/ld.exe: final link failed: File truncated
collect2: ld returned 1 exit status

C:\Documents and Settings\Administrator\Desktop\ldbug>

Now a old toolchain at 2.19

gcc version 3.4.5 (mingw-vista special r3)
GNU ld (GNU Binutils) 2.19.1
GNU dlltool (GNU Binutils) 2.19.1


ldbug, main.exe successfully built, on launching main.exe a fatal error GUI box pops up with "The procedure entry point MessageBoxDoesntExist could not be located in the dynamic link library user32.dll." as intended. No bug with 3.4.5/2.19.


Now a different older GCC

gcc version 4.4.0 (TDM-1 mingw32)
GNU ld (GNU Binutils) 2.19.1
GNU dlltool (GNU Binutils) 2.19.1


ldbug, main.exe successfully built, on launching main.exe a fatal error GUI box pops up with "The procedure entry point MessageBoxDoesntExist could not be located in the dynamic link library user32.dll." as intended. No bug with 4.4.0/2.19.

now for a very old binutils

gcc version 3.4.5 (mingw-vista special r3)
GNU ld version 2.17.50 20060824
GNU dlltool 2.17.50 20060824


ldbug, main.exe successfully built, on launching main.exe a fatal error GUI box pops up with "The procedure entry point MessageBoxDoesntExist could not be located in the dynamic link library user32.dll." as intended. No bug with 3.4.5/2.17.