Refactored SymbolInfo to lower memory usage in RTS

Previously as part of #11223 a new struct `SymbolInfo` was introduced to
keep track it the weak symbol status of a symbol.

This structure also kept a copy of the calculated address of the symbol
which turns out was useful in ignoring non-weak zero-valued symbols.

The information was kept in an array so it means for every symbol two
extra bytes were kept even though the vast majority of symbols are
non-weak and non-zero valued.

This changes the array into a sparse map keeping this information only
for the symbols that are weak or zero-valued. This allows for a
reduction in the amount of information needed to be kept while giving up
a small (negligable) hit in performance as this information now has to
be looked up in hashmaps.

Test Plan: ./validate on all platforms that use the runtime linker.

For unix platforms please ensure `DYNAMIC_GHC_PROGRAMS=NO` is added to
your validate file.

Reviewers: simonmar, austin, erikd, bgamari

Reviewed By: simonmar, bgamari

Subscribers: thomie, #ghc_windows_task_force

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

GHC Trac Issues: #11816

1 files changed, 25 insertions, 25 deletions

diff --git a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32 b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32
index af8ff1b1e8..151aab3817 100644
--- a/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32
+++ b/testsuite/tests/rts/T11223/T11223_simple_duplicate_lib.stderr-mingw32
@@ -1,25 +1,25 @@
-GHC runtime linker: fatal error: I found a duplicate definition for symbol

-   a

-whilst processing object file

-   E:/msys64/home/Tamar/ghc2/testsuite/tests/rts/T11223\libfoo_dup_lib.a

-The symbol was previously defined in

-   bar_dup.o

-This could be caused by:

-   * Loading two different object files which export the same symbol

-   * Specifying the same object file twice on the GHCi command line

-   * An incorrect `package.conf' entry, causing some object to be

-     loaded twice.

-

-ByteCodeLink: can't find label

-During interactive linking, GHCi couldn't find the following symbol:

-  c

-This may be due to you not asking GHCi to load extra object files,

-archives or DLLs needed by your current session.  Restart GHCi, specifying

-the missing library using the -L/path/to/object/dir and -lmissinglibname

-flags, or simply by naming the relevant files on the GHCi command line.

-Alternatively, this link failure might indicate a bug in GHCi.

-If you suspect the latter, please send a bug report to:

-  glasgow-haskell-bugs@haskell.org

-

-ghc-stage2.exe: Could not on-demand load symbol 'c'

-

+GHC runtime linker: fatal error: I found a duplicate definition for symbol
+   a
+whilst processing object file
+   E:/msys64/home/Tamar/ghc2/testsuite/tests/rts/T11223\libfoo_dup_lib.a
+The symbol was previously defined in
+   bar_dup_lib.o
+This could be caused by:
+   * Loading two different object files which export the same symbol
+   * Specifying the same object file twice on the GHCi command line
+   * An incorrect `package.conf' entry, causing some object to be
+     loaded twice.
+
+ByteCodeLink: can't find label
+During interactive linking, GHCi couldn't find the following symbol:
+  c
+This may be due to you not asking GHCi to load extra object files,
+archives or DLLs needed by your current session.  Restart GHCi, specifying
+the missing library using the -L/path/to/object/dir and -lmissinglibname
+flags, or simply by naming the relevant files on the GHCi command line.
+Alternatively, this link failure might indicate a bug in GHCi.
+If you suspect the latter, please send a bug report to:
+  glasgow-haskell-bugs@haskell.org
+
+ghc-stage2.exe: Could not on-demand load symbol 'c'
+