<div dir="ltr">Even if MR388 ( <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388</a> ) is the cause of the issue we're seeing with the API exposed by Clash, I still think MR388 is wrong.<br>My reasoning is the following:<br><br>In 8.8 and earlier we had:<br>- RTS C-code contains the ground truth of what is linked. The API it provides are set-membership, insert, lookup, and delete. Notably it does not allow you to get the set of linked objects.<br>- There is a globally shared MVar (using NOINLINE, sharedCaf, unsafePerformIO newIORef "tricks") to what is basically a log/view of the linked-objects state kept by the RTS C-code.<br><br>With MR388, in 8.10 and later we get:<br>- RTS C-code contains the ground truth of what is linked. The API it provides are set-membership, insert, lookup, and delete. Notably it does not allow you to get the set of linked objects.<br><div>- A _new_ MVar for every call to `runGhc` which is a log/view of the linked-object state kept by the RTS C-code. But that means these MVar get out-of-sync with the ground truth that is the RTS C-code! And since the RTS C-code does not expose an API to get the set of linked objects, there's no way to sync these MVars either!</div><div><br></div><div>I'm building a ghc-8.10.2 with MR388 reverted to see whether it is indeed what is causing the issue we're seeing in Clash.</div><div>Given my analysis above of what I think is wrong with MR388, I'm not saying we should completely revert MR388, but simply ensure that every HscEnv created through `runGhc` gets the globally shared MVar; as opposed to the current call to `newMVar`.<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 7 Mar 2021 at 04:02, ÉRDI Gergő <<a href="mailto:gergo@erdi.hu">gergo@erdi.hu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thanks Matthew and Julian! Unfortunately, trying out GHC before/after this <br>
change didn't turn out to be as easy as I hoped: to do my testing, I <br>
need to build a given GHC commit, and then use that via Stack to install <br>
~140 dependencies so that I can then test the problem I have initially <br>
seen. And it turns out doing that with a random GHC commit is quite <br>
painful because in any given Stackage snapshot there will be packages with <br>
which the GHC-bundled libraries are incompatible... :/<br>
<br>
<br>
<br>
On Thu, 4 Mar 2021, Julian Leviston wrote:<br>
<br>
> Hi,I don’t know enough about what Clash does to comment really, but it sounds like<br>
> it’s to do with my work on enabling multiple linker instances<br>
> in <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/388</a> — maybe reading through<br>
> that or the plan I outlined at <a href="https://gitlab.haskell.org/ghc/ghc/-/issues/3372" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/issues/3372</a> might<br>
> help, though I’m not sure.<br>
> <br>
> Strange, though, as this work was to isolate state in GHC — to change it from using a<br>
> global IORef to use a per-process MVar . But it definitely did change the way state is<br>
> handled, so it might be the related to these issues somehow?<br>
> <br>
> I realise this isn’t much help, but maybe it points you in a direction where you can<br>
> begin to understand some more.<br>
> <br>
> Julian<br>
><br>
>       On 4 Mar 2021, at 10:55 pm, ÉRDI Gergő <<a href="mailto:gergo@erdi.hu" target="_blank">gergo@erdi.hu</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> I'm trying to figure out a Clash  problem and managed to track it down to a GHC<br>
> upgrade; specifically, a given Clash version, when based on GHC 8.8, has no<br>
> problem synthesizing one module after another from one process; but the same<br>
> Clash version with GHC 8.10 fails with link-time errors on the second<br>
> compilation.<br>
> <br>
> The details are at <a href="https://github.com/clash-lang/clash-compiler/issues/1686" rel="noreferrer" target="_blank">https://github.com/clash-lang/clash-compiler/issues/1686</a><br>
> but for now I'm just hoping that some lightbulb will go off for someone if some<br>
> handling of internal state has changed in GHC that could mean that the symbol<br>
> tables of loaded modules could persist between GHC invocations from the same<br>
> process.<br>
> <br>
> So, does this ring a bell for anyone?<br>
> <br>
> Thanks,<br>
> Gergo<br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
> <br>
> <br>
> <br>
><br>
<br>
-- <br>
<br>
   .--= ULLA! =-----------------.<br>
    \     <a href="http://gergo.erdi.hu" rel="noreferrer" target="_blank">http://gergo.erdi.hu</a>   \<br>
     `---= <a href="mailto:gergo@erdi.hu" target="_blank">gergo@erdi.hu</a> =-------'<br>
I tried to commit suicide once by taking over 1,000 aspirin. But after I took 2, I felt better!_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div></div>