[GHC] #14018: Highlight differences of Frontend Plugin vs GHC API

[GHC]

#14018: Highlight differences of Frontend Plugin vs GHC API
-------------------------------------+-------------------------------------
        Reporter:  literon           |                Owner:  (none)
            Type:  feature request   |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1-rc2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by literon):

 Could do the writeup once the problem / solution crystallizes.

 It's not clear to me yet that (not) unloading non-Haskell objects is a
 fundamental limitation or just a missing feature. I was looking around,
 and for the uneducated sight the problem seems to be this:

 `preload_static` [1] in Linker.hs (called eventually by `loadCmdLineLibs`)
 calls either `dynLoadObjs` or `loadObj`, depending on `dynamicGHC`. But
 neither of those do any bookkeeping for `PersistentLinkerState`. It seems
 calling `dynLinkObjs` [2] (note `Link` not `Load` in name) would be more
 appropriate, since it updates the `objs_loaded` in `PLS`, so a later
 `unload` call could unload those as well.

 This sounds more in line with the Linker comment that `PLS` should be
 synced with the C linker state. However `dynLinkObjs`, while morally doing
 the same as `preload_static` + accounting, conditionally chooses
 `dynLoadObjs` or `loadObj` based on `dynamicInterpreter`. Latter seems to
 be defined the same as `dynamicGhc` except if an external interpreter is
 used, which I have no idea about.

 It would be insightful if someone knowledgeable about the linker code
 could comment if this has good reasons and a change is not feasible, or
 maybe is just historic leftover.

 [1]:
 http://stuff.codereview.me/#ghc/compiler/ghci/Linker.hs?corpus=ghc-8.2.1-rc2&signature&line=472
 [2]:
 http://stuff.codereview.me/#ghc/compiler/ghci/Linker.hs?corpus=ghc-8.2.1-rc2&signature&line=854

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