Better import library support for Windows

The import library support added for 7.10.3 was only a partial one.
This support was predicated on using file extensions to determine
whether or not a library was an import library. It also couldn't handle
libraries with multiple dll pointers.

This is a rewrite of that patch and fully integrating it into the normal
archive parsing and loading routines. This solves a host of issues,
among others allowing us to finally use `-lgcc_s`.

This also fixes a problem with our previous implementation, where we
just loaded the DLL and moved on. Doing this had the potential of using
the wrong symbol at resolve time. Say a DLL already loaded (A.dll) has
symbol a exported (dependency of another dll perhaps).

We find an import library `B.lib` explicitly defining an export of `a`.
we load `B.dll` but this gets put after `A.dll`, at resolve time we
would use the value from `A` instead of `B` which is what we wanted.

Test Plan: ./valide and make test TEST=13606

Reviewers: austin, bgamari, erikd, simonmar

Reviewed By: bgamari

Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force

GHC Trac Issues: #13606, #12499, #12498

Differential Revision: https://phabricator.haskell.org/D3513

1 files changed, 4 insertions, 1 deletions

diff --git a/rts/Linker.c b/rts/Linker.c
index 65caf89f6e..6e710a1431 100644
--- a/rts/Linker.c
+++ b/rts/Linker.c
@@ -230,6 +230,9 @@ static void ghciRemoveSymbolTable(HashTable *table, const SymbolName* key,
     RtsSymbolInfo *pinfo = lookupStrHashTable(table, key);
     if (!pinfo || owner != pinfo->owner) return;
     removeStrHashTable(table, key, NULL);
+    if (isSymbolImport (owner, key))
+      stgFree(pinfo->value);
+
     stgFree(pinfo);
 }
 
@@ -731,7 +734,7 @@ addDLL( pathchar *dll_name )
    return errmsg;
 
 #  elif defined(OBJFORMAT_PEi386)
-   return addDLL_PEi386(dll_name);
+   return addDLL_PEi386(dll_name, NULL);
 
 #  else
    barf("addDLL: not implemented on this platform");