GHC (API?) question: GHC Core for Base libraries

Shao, Cheng cheng.shao at tweag.io
Tue Dec 4 03:09:40 UTC 2018


Hi,

Joachim Breitner's veggies(https://github.com/nomeata/veggies) project is a
good example of using a vanilla ghc installation to compile standard
libraries like base.

On Tue, Dec 4, 2018, 10:11 AM Bill Hallahan <william.hallahan at yale.edu>
wrote:

> Hi,
>
> I'm writing a program analyzer that operates on GHC Core.  Currently, I'm
> using the GHC API to get Core from .hs files.  I'd like to be able to run
> this analysis on the standard libraries that come with GHC, which requires
> getting those as Core.
>
> Unfortunately, the build process for these libraries is not entirely
> straightforward, and relies on a make script.  I eventually came up with
> the plan of writing a GHC plugin, which, rather than performing any
> optimizations, would simply run the analysis, and then print the results
> out to a file.  I was able to write the plugin successfully, and test it on
> several files that were *not* from the base library.
>
> Then, i turned to modify the GhcLibHcOpts flag in mk/build.mk, so that
> the make script would call the plugin.  I ended up with the following:
>
> GhcLibHcOpts = -package-db /usr/local/lib/ghc-8.0.2/package.conf.d
> -package-db /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d
> -package hplugin -fplugin HPlugin.Plugin -v
>
> The two package databases are to get to (1) the GHC API and (2) the plugin
> ("hplugin") itself.  With this I get an error message, which I have not
> been able to find a way to resolve:
>
> "inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -H32m -O
> -Wall      -this-unit-id ghc-prim-0.5.0.0 -hide-all-packages -i
> -ilibraries/ghc-prim/. -ilibraries/ghc-prim/dist-install/build
> -ilibraries/ghc-prim/dist-install/build/autogen
> -Ilibraries/ghc-prim/dist-install/build
> -Ilibraries/ghc-prim/dist-install/build/autogen -Ilibraries/ghc-prim/.
> -optP-include
> -optPlibraries/ghc-prim/dist-install/build/autogen/cabal_macros.h
> -package-id rts -this-unit-id ghc-prim -XHaskell2010 -package-db
> /usr/local/lib/ghc-8.0.2/package.conf.d -package-db
> /Users/BillHallahan/.ghc/x86_64-darwin-8.0.2/package.conf.d -package
> hplugin -fplugin HPlugin.Plugin  -no-user-package-db -rtsopts
> -Wno-trustworthy-safe -Wno-deprecated-flags
> -Wnoncanonical-monad-instances  -odir libraries/ghc-prim/dist-install/build
> -hidir libraries/ghc-prim/dist-install/build -stubdir
> libraries/ghc-prim/dist-install/build -split-objs  -dynamic-too -c
> libraries/ghc-prim/./GHC/Types.hs -o
> libraries/ghc-prim/dist-install/build/GHC/Types.o -dyno
> libraries/ghc-prim/dist-install/build/GHC/Types.dyn_o
> <command line>: not built for interactive use - can't load plugins
> (HPlugin.Plugin)
> make[1]: *** [libraries/ghc-prim/dist-install/build/GHC/Types.o] Error 1
> make: *** [all] Error 2
>
> So I'm now wondering (an answer to either of these two questions would be
> helpful):
> (1) Is this a viable path?  That is, is it possible to use a plugin when
> building Base?  If so, does anyone know what I might be doing wrong/what
> could be causing this error message?
> (2) Is there some other better/easier way I could get Core representations
> of the standard libraries?  I guess, in theory, it must be possible to
> compile the standard libraries with the GHC API, but I have no idea
> how/where to look to figure out how?
>
> Thanks,
> Bill
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20181204/f7dc857d/attachment.html>


More information about the ghc-devs mailing list