- ghc-devs - Haskell.org

Running GHC 7.10.2 on Ubuntu 18.04 ?
by Ömer Sinan Ağacan 05 Sep '18

05 Sep '18

Hi, I'm trying to use GHC 7.10.2 (the Debian 8 bindist from haskell.org) on Ubuntu 18.04. It's currently failing with linker errors when I compile `main = return ()`: /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__5.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Base__125.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Signal__13.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Sync__199.o): relocation R_X86_64_32S against `.text' can not be used when making a PIE object; recompile with -fPIC /usr/bin/x86_64-linux-gnu-ld: /home/omer/ghc_bins/ghc-7.10.3-bin/lib/ghc-7.10.3/base_HQfYBxpPvuw8OunzQu6JGM/libHSbase-4.8.2.0-HQfYBxpPvuw8OunzQu6JGM.a(Exception__170.o): relocation R_X86_64_32S against symbol `stg_bh_upd_frame_info' can not be used when making a PIE object; recompile with -fPIC I'm getting about 700 of these. Does anyone know a way to make GHC 7.10.2 work on Ubuntu 18.04? Not sure if related but the ld version is ~ $ /usr/bin/x86_64-linux-gnu-ld --version GNU ld (GNU Binutils for Ubuntu) 2.30 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. Thanks, Ömer

2 2

Re: Running GHC 7.10.2 on Ubuntu 18.04 ?
by Ryan Scott 05 Sep '18

05 Sep '18

This is likely caused by an old GHC bug that interacts poorly with newer version of binutils (I can't remember the exact bug, unfortunately). I personally use hvr's Ubuntu PPA [1] whenever installing GHC on Ubuntu. This PPA backports patches to old versions of GHC to keep them working with newer versions of binutils, and I can confirm that the version of GHC 7.10.2 offered from here works well with Ubuntu 18.04. Ryan S. ----- [1] https://launchpad.net/~hvr/+archive/ubuntu/ghc

1 0

Rational for the special case in mkWWcpr_help
by Spiwack, Arnaud 05 Sep '18

05 Sep '18

Dear all, The function mkWWcpr_help, which creates a wrapper and a worker after strictness analysis, has a special case when there is a single result of unlifted type: Wrapper: case (..call worker..) of x -> C x Worker: case ( ..body.. ) of C x -> x But I don't understand how it is different from using (# #) as would result from the general case: Wrapper: case (..call worker..) of (# x #) -> C x Worker: case ( ..body.. ) of C x -> (# x #) That is, my understanding of the latter is that it would yield the exact same code. I'm obviously missing something, I'd love to know what. Best, Arnaud

2 1

Does tyCoVarsOfTypesList guarantee a particular order?
by Ryan Scott 05 Sep '18

05 Sep '18

tyCoVarsOfTypesList guarantees that it returns its answer in a deterministic order. For the longest time, I must have assumed that this order was left to right. However, it appears that my assumption was wrong! This can be demonstrated with this program: module Main where import Name import TyCoRep import TysPrim import Var main :: IO () main = do putStrLn "(1)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar] putStrLn "(2)" print $ map (getOccString . tyVarName) $ tyCoVarsOfTypesList [TyVarTy alphaTyVar, TyVarTy betaTyVar, TyVarTy alphaTyVar] This gives the following output: (1) ["a","b"] (2) ["b","a"] The first one makes total sense to me. The second, one however, does not. If the free variables of that list were returned in left-to-right order (or even right-to-left order!), then (2) should give the same answer as (1). Instead, it lists "b" _before_ "a", which I find incredibly baffling. To explain why I care so much about this, we're currently trying to improve Haddock's logic for choosing when to put explicit `forall`s in front of types [1]. Our litmus test is this: if the order in which a user wrote the `forall`d variables differs from the order in which the free variables of the body would normally occur, then have Haddock display an explicit forall. I would have assumed that tyCoVarsOfTypesList [2] would be enough to determine the "normal" order of the free variables, but as the example above proves, this sometimes gives unexpected orderings when there are multiple occurrences of the same variable. We are currently having to work around this issue [1] by implementing our own custom versions of tyCoFVsOfType and friends that accumulate variables in reverse order (and then reversing the list at the end!) to get the order we expect. This feels incredibly wasteful to me, so I'd like to know if there's a better way. In particular: 1. Is this behavior of tyCoVarsOfTypesList expected? 2. If not, should we change it? Ryan S. ----- [1] See https://github.com/haskell/haddock/pull/931 [2] Actually, I would use tyCoVarsOfTypesWellScoped, but dependency order doesn't come into play in the example I gave above.

2 1

Re: Unpacking coercions
by Ryan Scott 04 Sep '18

04 Sep '18

In case this wasn't clear, the context of this discussion in this GHC proposal [1], where David is trying to work around the fact that data types with existential Coercible constraints do not support unpacking. (By "unpacking", I mean putting an {-# UNPACK #-} pragma in front of a field of that type does what you would expect.) An example program which demonstrates the performance issue can be found here [2]. That comment concerns unboxed equality vs. boxed equality, but the same unpacking problems that affect boxed equality also affect Coercible. Ryan S. ----- [1] https://github.com/ghc-proposals/ghc-proposals/pull/116 [2] https://github.com/ghc-proposals/ghc-proposals/pull/116#issuecomment-382346…

2 1

RE: Hadrian
by Andrey Mokhov 04 Sep '18

04 Sep '18

Thanks Simon, I fixed the "verboseCommands" typo. Regarding various available predicates: indeed, we don't currently have a comprehensive description -- I've opened an issue for this and will hopefully fix it soon. In the meanwhile, there are a few examples of predicates in the rest of the doc/user-settings.md document, for example here: https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#com…. The `input` and `output` predicates accept Shake's `FilePattern` as parameters -- see the documentation for it here: https://hackage.haskell.org/package/shake-0.16.4/docs/Development-Shake.htm… Cheers, Andrey -----Original Message----- From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 04 September 2018 16:49 To: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk>; Alp Mestanogullari <alp(a)well-typed.com> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Very confusingly https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#ver… speaks about verboseCommmands PLURAL, whereas it should say verboseCommand SINGLUAR. Moreover, what is the language things you can say (i.e. where is it documented). The "//" business, and what patterns can occur. What things other than "//" can you have? What about 'input' etc? Simon | -----Original Message----- | From: Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> | Sent: 30 August 2018 12:26 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari | <alp(a)well-typed.com> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: RE: Hadrian | | Simon, | | If you want to see all command lines, you can pass '--verbose' or '-V' | flag to Hadrian and it will then print out everything it does. | | But you can also choose which particular command lines to print in | UserSettings, see: | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md%23verbose-command- | lines&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508 | d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140342623 | 1&sdata=tMYhmIGMeVbBYjAtxWQTY5%2F4Kyfc4m981N4OTowGkbQ%3D&reserved | =0 | | So, you can do: | | verboseCommand = input "//GHC/Real.hs" | | Or, alternatively, | | verboseCommand = output "//GHC/Real.hi" | | Both should produce the same result (in theory). | | In general, we have the following documents on Hadrian: | | The README: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2FREADME.md&data=02%7C01%7 | Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f988bf86f | 141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=7WigmQG7lbDd | eyhYCSaKOQEb0eeZcn0iXAbAKdwZ5A4%3D&reserved=0 | How to use UserSettings: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fuser- | settings.md&data=02%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269 | efd508d60e6b4fe7%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63671225140 | 3426231&sdata=tRu2lO%2F6TNV3ao5tzNKO%2FAHJMWsxKX%2BqExHn78nuCvU%3D&am | p;reserved=0 | An overview of build flavours: | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.c | om%2Fsnowleopard%2Fhadrian%2Fblob%2Fmaster%2Fdoc%2Fflavours.md&data=0 | 2%7C01%7Csimonpj%40microsoft.com%7C0c6118a504f74269efd508d60e6b4fe7%7C72f | 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636712251403426231&sdata=Esye | DdAKLV9DC3PUwkqsuQ4zGoOYKcaJeEov1BAH8lU%3D&reserved=0 | | I hope the more Hadrian gets used, the more complete the documentation | will become. | | Cheers, | Andrey | | From: Simon Peyton Jones [mailto:simonpj@microsoft.com] | Sent: 30 August 2018 12:19 | To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari | <alp(a)well-typed.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: RE: Hadrian | | Sigh. As an inconvenient workaround, I tried adding {-# OPTIONS_GHC - | dverbose-core2core #-} to GHC.Real, and then doing | cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." | in hadrian/ | That did recompile GHC.Real - but all the debug output disappeared! | I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that | didn't work. | I'm stuck - any ideas? | Simon | | From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Simon Peyton | Jones via ghc-devs | Sent: 30 August 2018 12:12 | To: Alp Mestanogullari <alp(a)well-typed.com>; Andrey Mokhov | <andrey.mokhov(a)newcastle.ac.uk> | Cc: ghc-devs <ghc-devs(a)haskell.org> | Subject: Hadrian | | Alp, Andrey | The old build system printed out every command line; and I often copy- | paste that info to build single modules. | Eg currently, when trying to understand #15570 I see a suspicious | GHC.Real.hi. So I want to manually recompile GHC.Real (from base), | adding some debug flags. How can I get the right command line to do that | from the build log? | Where is the "how to use Hadrian" wiki page? I know you've been writing | one. | Simon

2 1

Is combining StaticPointers and TemplateHaskell safe?
by Matthew Pickering 04 Sep '18

04 Sep '18

I can implement a function which acts like `lift` using static pointers in the following way: ``` liftS :: StaticPtr a -> Q (TExp a) liftS sp = let sk = staticKey sp in [|| deRefStaticPtr (fromJust (unsafePerformIO (unsafeLookupStaticPtr sk))) ||] ``` The question, is this safe in general? It seems to me that this referencing should be safe because I could have achieved the same without quoting using `deRefStaticPtr` directly. The only reason I have to use the `unsafeLookup` function is because `StaticPtr` is not an instance of `Lift`. However, it's a bit annoying that this lookup has to be deferred to runtime, would it be acceptable to add an extra field to `StaticPtr a` which contained a `TExp a` value? Then the implementation of `liftS` just extracts this value from the `StaticPtr`. Using `static` is preferable to using `lift` in many situations as `Lift` is implemented using a type class it can't lift things such as 1. functions and 2. top-level identifiers. Further to this, it's annoying to have to incur a `Lift a` constraint when trying to lift `Nothing`. `static` has none of these problems. Cheers, Matt

2 1

RE: Hadrian
by Andrey Mokhov 04 Sep '18

04 Sep '18

Simon, If you want to see all command lines, you can pass '--verbose' or '-V' flag to Hadrian and it will then print out everything it does. But you can also choose which particular command lines to print in UserSettings, see: https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md#ver… So, you can do: verboseCommand = input "//GHC/Real.hs" Or, alternatively, verboseCommand = output "//GHC/Real.hi" Both should produce the same result (in theory). In general, we have the following documents on Hadrian: The README: https://github.com/snowleopard/hadrian/blob/master/README.md How to use UserSettings: https://github.com/snowleopard/hadrian/blob/master/doc/user-settings.md An overview of build flavours: https://github.com/snowleopard/hadrian/blob/master/doc/flavours.md I hope the more Hadrian gets used, the more complete the documentation will become. Cheers, Andrey From: Simon Peyton Jones [mailto:simonpj@microsoft.com] Sent: 30 August 2018 12:19 To: Simon Peyton Jones <simonpj(a)microsoft.com>; Alp Mestanogullari <alp(a)well-typed.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: RE: Hadrian Sigh. As an inconvenient workaround, I tried adding {-# OPTIONS_GHC -dverbose-core2core #-} to GHC.Real, and then doing cabal new-run hadrian -- -c -j4 --flavour=quick --directory=".." in hadrian/ That did recompile GHC.Real - but all the debug output disappeared! I tried adding {-# OPTIONS_GHC -ddebug-output #-} as well, but that didn't work. I'm stuck - any ideas? Simon From: ghc-devs <ghc-devs-bounces(a)haskell.org> On Behalf Of Simon Peyton Jones via ghc-devs Sent: 30 August 2018 12:12 To: Alp Mestanogullari <alp(a)well-typed.com>; Andrey Mokhov <andrey.mokhov(a)newcastle.ac.uk> Cc: ghc-devs <ghc-devs(a)haskell.org> Subject: Hadrian Alp, Andrey The old build system printed out every command line; and I often copy-paste that info to build single modules. Eg currently, when trying to understand #15570 I see a suspicious GHC.Real.hi. So I want to manually recompile GHC.Real (from base), adding some debug flags. How can I get the right command line to do that from the build log? Where is the "how to use Hadrian" wiki page? I know you've been writing one. Simon

3 3

Re: Unpacking coercions
by Ryan Scott 04 Sep '18

04 Sep '18

If we can gain some performance from this, then I'm generally supportive of this idea. I'm still of the belief that we could teach GHC to unpack boxed equality constraints, but your idea would definitely be the simpler one to implement. Ryan S.

2 1

Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19)
by Dominique Devriese 04 Sep '18

04 Sep '18

(apologies if you receive multiple copies of this announcement) ======================================================================= Call for Presentations on Secure Compilation (PriSC Workshop @ POPL'19) ======================================================================= The emerging field of secure compilation aims to preserve security properties of programs when they have been compiled to low-level languages such as assembly, where high-level abstractions don’t exist, and unsafe, unexpected interactions with libraries, other programs, the operating system and even the hardware are possible. For unsafe source languages like C, secure compilation requires careful handling of undefined source-language behavior (like buffer overflows and double frees). Formally, secure compilation aims to protect high-level language abstractions in compiled code, even against adversarial low-level contexts, thus enabling sound reasoning about security in the source language. A complementary goal is to keep the compiled code efficient, often leveraging new hardware security features and advances in compiler design. Other necessary components are identifying and formalizing properties that secure compilers must possess, devising efficient security mechanisms (both software and hardware), and developing effective verification and proof techniques. Research in the field thus puts together advances in compiler design, programming languages, systems security, verification, and computer architecture. ============================================================= 3rd Workshop on Principles of Secure Compilation (PriSC 2019) ============================================================= The Workshop on Principles of Secure Compilation (PriSC) is a relatively new, informal 1-day workshop without any proceedings. The goal is to bring together researchers interested in secure compilation and to identify interesting research directions and open challenges. The 3rd edition of PriSC will be held in Lisbon, together with the ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages (POPL), 2019. The exact date will be either January 13 or January 19 (to be decided by the POPL organizers). More information is available at http://popl19.sigplan.org/track/prisc-2019 Important Dates * Presentation proposal submission deadline: 17 October 2018, AoE * Presentation proposal notification: 10 November 2018 * PriSC Workshop takes place: either Sunday, 13 January 2019 or Saturday 19 January 2019 (to be decided by the POPL organizers) ================================================= Presentation Proposals and Attending the Workshop ================================================= Anyone interested in presenting at the workshop should submit an extended abstract (up to 2 pages, details below) covering past, ongoing, or future work. Any topic that could be of interest to secure compilation is in scope. Secure compilation should be interpreted very broadly to include any work in security, programming languages, architecture, systems or their combination that can be leveraged to preserve security properties of programs when they are compiled or to eliminate low-level vulnerabilities. Presentations that provide a useful outside view or challenge the community are also welcome. This includes presentations on new attack vectors such as microarchitectural side-channels, whose defenses could benefit from compiler techniques. Specific topics of interest include but are not limited to: * attacker models for secure compiler chains. * secure compiler properties: fully abstract compilation and similar properties, memory safety, control-flow integrity, preservation of safety, information flow and other (hyper-)properties against adversarial contexts, secure multi-language interoperability. * secure interaction between different programming languages: foreign function interfaces, gradual types, securely combining different memory management strategies. * enforcement mechanisms and low-level security primitives: static checking, program verification, typed assembly languages, reference monitoring, program rewriting, software-based isolation/hiding techniques (SFI, crypto-based, randomization-based, OS/hypervisor-based), security-oriented architectural features such as Intel’s SGX, MPX and MPK, capability machines, side-channel defenses, object capabilities. * experimental evaluation and applications of secure compilers. * proof methods relevant to compilation: (bi)simulation, logical relations, game semantics, trace semantics, multi-language semantics, embedded interpreters. * formal verification of secure compilation chains (protection mechanisms, compilers, linkers, loaders), machine-checked proofs, translation validation, property-based testing. ============================================ Guidelines for Submitting Extended Abstracts ============================================ Extended abstracts should be submitted in PDF format and not exceed 2 pages. They should be formatted in two-column layout, 10pt font, and be printable on A4 and US Letter sized paper. We recommend using the new acmart LaTeX style in sigplan mode: http://www.sigplan.org/sites/default/files/acmart/current/acmart-sigplanpro… Submissions are not anonymous and should provide sufficient detail to be assessed by the program committee. Presentation at the workshop does not preclude publication elsewhere. Please submit your extended abstracts at https://prisc19.hotcrp.com/. ============================ Contact and More Information ============================ For questions please contact the workshop chairs, Dominique Devriese ( dominique.devriese(a)cs.kuleuven.be) and Deepak Garg (dg(a)mpi-sws.org) To make sure you receive such announcements in the future please subscribe to the following low-traffic mailing list: https://lists.gforge.inria.fr/mailman/listinfo/prisc-announce

1 0