#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