[GHC] #12388: Don't barf on failures in the RTS linker

[GHC]

#12388: Don't barf on failures in the RTS linker
-------------------------------------+-------------------------------------
           Reporter:  dobenour       |             Owner:
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:  8.2.1
          Component:  Runtime        |           Version:  8.0.1
  System (Linker)                    |
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  None/Unknown
  Unknown/Multiple                   |
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 The RTS linker currently calls `barf()` when it fails.  This is a problem
 because:

  1. It appears that there is a bug in GHC, when there is no bug.
  2. Failures to load code really should be recoverable.

 According to a `TODO` in the code, the culprit is resource deallocation,
 which is very difficult due to the code being written in C and having
 complicated control flow.  There are a few solutions:

  - Port the RTS linker to C++ and use RAII for resource management.
 Failures would be handled (internally to the linker) by throwing a C++
 exception.  This is actually my favorite, but might not be popular with
 the GHC devs.
  - Build a huge context struct containing all needed resources and free it
 before returning.  Signal errors with `longjmp()`.
  - Try to find each and every place where resources need to be free, and
 free them by hand.  Signal errors with return codes.  This seems too
 error-prone.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12388>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler