August 2015 - ghc-devs

RE: Building on Windows
by Tamar Christina 21 Aug '15

21 Aug '15

Hi Michael, Those instructions are for the GHC head. For 7.10 and earlier this page https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources/Legacy should have been updated but it seems it never was.. To get the tarballs on that version do git clone git://git.haskell.org/ghc-tarballs.git I will update the legacy page later. Regards, Tamar ------------------------------ From: Michael Snoyman <michael(a)snoyman.com> Sent: ‎8/‎21/‎2015 7:06 To: ghc-devs(a)haskell.org Subject: Building on Windows I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331

2 2

Building on Windows
by Michael Snoyman 21 Aug '15

21 Aug '15

I'm trying to test a patch I wrote for Windows builds[1]. I'm following the preparation guide[2], but my configure step fails[3] with config.log contents[4]. Note that I'm building on the ghc-7.10 branch, not master. Is it possible that this would contribute to the unrecognized --enable-tarballs-autodownload option, and/or the inability to compile C files? [1] https://phabricator.haskell.org/D1158, handles long linker command line arguments [2] https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows [3] http://lpaste.net/139330 [4] http://lpaste.net/139331

1 0

Deleting sync-all
by Thomas Miedema 20 Aug '15

20 Aug '15

Hello ghc-devs, I would like to delete the file sync-all <https://ghc.haskell.org/trac/ghc/wiki/Building/SyncAll> from the GHC repository. It should not have been necessary to use it for about a year now. To get the sources <https://ghc.haskell.org/trac/ghc/wiki/Building/GettingTheSources>: git clone --recursive git://git.haskell.org/ghc.git cd ghc git clone git://git.haskell.org/ghc-tarballs.git # Windows only To update an existing tree <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#Upd…>: git pull --rebase git submodule update --init To update an existing tree <https://ghc.haskell.org/trac/ghc/wiki/WorkingConventions/Git/Submodules#git…>, without the possibility to forget to run `git submodule update --init`: git config --global alias.pullall '!f(){ git pull --ff-only "$@" && git submodule update --init --recursive; }; f' # Run once git pullall --rebase Please speak up if you want those 1000 lines of buggy Perl a.k.a. sync-all to stay for some reason, or if you have questions about a certain git submodules workflow. The source code (./boot no longer suggests it) and the wiki are already sync-all free, except for a few historical pages. Discussion period: 1 month. Thomas

3 5

Linker questions
by lonetiger＠gmail.com 19 Aug '15

19 Aug '15

Hi *, I had a few questions about the linker I was hoping someone can help me with, I'm pretty new to it so any insights would be appreciated. 1) Has to do with checkProddableBlock and #10672 and #10563 static void checkProddableBlock (ObjectCode *oc, void *addr, size_t size ) { ProddableBlock* pb; for (pb = oc->proddables; pb != NULL; pb = pb->next) { char* s = (char*)(pb->start); char* e = s + pb->size; char* a = (char*)addr; if (a >= s && (a+size) <= e) return; } barf("checkProddableBlock: invalid fixup in runtime linker: %p", addr); } >From what I have found, these errors seem to happen because oc->proddables is initially NULL, the for loop is skipped. From what I can tell, this function is checking if there's a "proddable" that fits within the supplied address and size. So if there is no proddables to begin with, should this check just not be skipped and the callee of this call not use this ObjectCode instead of erroring out? 2) The second question is about static int ocGetNames_PEi386 ( ObjectCode* oc ) I am getting a test failure because it is claiming that .eh_frame section is misaligned. This comes from this code: if (kind != SECTIONKIND_OTHER && end >= start) { if ((((size_t)(start)) % 4) != 0) { errorBelch("Misaligned section %s: %p", (char*)secname, start); stgFree(secname); return 0; } Where start is defined as: start = ((UChar*)(oc->image)) + sectab_i->PointerToRawData; and oc->image is a memory location received by allocateImageAndTrampolines. In the case of my test failure it is because the .eh_frame section seems to begin at 0x30F since oc->image will always be 4 aligned (so it doesn't really matter in the check) it gives that error because PointerToRawData isn't aligned by 4. So my question is would it not be better just to check the alignment flag in the PE section header instead of checking the load address (which is always going to aligned to 4?) and The file pointer to the first page of the section within the COFF file to determine the alignment? Like objdump and dumpbin do? e.g. 9 .eh_frame 00000038 00000000 00000000 0000030f 2**2 CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA Is the output from objdump which correctly determines the alignment from the section. From what I understand from the PE specification the on disk address doesn't have to be aligned by 4: "For object files, the value *should* be aligned on a 4-byte boundary for best performance." I'm wondering if we are incorrectly erroring out here, instead of using the section and making sure we pad it to the alignment boundary. Regards, Tamar

4 4

getting addDependFile from a hi file
by Njagi Mwaniki 16 Aug '15

16 Aug '15

Hello, I have a case in which I wish to parse a hi file to extract the addDependentFile section created by template haskell. I found the function `readBinIface :: CheckHiWay -> TraceBinIFaceReading -> FilePath -> TcRnIf a b ModIface` https://downloads.haskell.org/~ghc/7.10.2/docs/html/libraries/ghc-7.10.2/Bi… I want to use the ModIface type to extract the mi_usages where I believe I will find the list of dependent files. The issue is that I can't extract a value of type ModIface due to the strict dependence on Env of values that are related to this. I don't understand what env is and despite reading about the docs extensively I can't find a function explaining how to work with the env value or how to generate one. The closest thing I found was in TcRnMonad.getTopEnv but even that is cryptic. Could I get some help. All in all, I just want to get the addDependFile section from a hi file.

2 1

A question about roles.
by Alexander Eyers-Taylor 16 Aug '15

16 Aug '15

Hello I have noticed in looking at some core that GADT type constructors are often applied with a representational role. These constructors are explicitly marked as nominal. Is this information just ignored at a Core level or is this invalid core? Looking at the code a see that we if we downgrade a TyConAppCo we unconditionally change it to a representational role after changing its children. I think this is where it is introduced. Alex ET

2 4

problem running on arm
by Luka Rahne 16 Aug '15

16 Aug '15

Hello everyone I am new here and I have build crosscompiler for RedPitaya (http://redpitaya.com) but now i am unable to run hello world. (main = putStrLn "hello world") Running with +RTS -Gg -RTS prints out bunch of data. What I think is going on is that GC consumes all memory. Here is one output on device. (using larger heap just takes more time and produces longer output) https://gist.github.com/ra1u/ab7ab0c23b86436a09ae In qemu everything is working fine. here is ghc verbose output for compilation https://gist.github.com/ra1u/ed376dc81ea21cd5a66b If somebody has some pointers to share i would be very happy. best regards, Luka Rahne

2 2

How to use pprTrace ?
by Omar Mefire 15 Aug '15

15 Aug '15

Hi all,I'm trying to step through some ghc code.I am trying to use pprTrace ( for the first time ) and I keep getting an error when I use it :I've added it to the file ghc/Main.hs and the resulting code is this : let argv1' = map (mkGeneralLocated "on the commandline") argv1 (argv2, staticFlagWarnings) <- pprTrace "argv1 prime" (ppr argv1') $ parseStaticFlags argv1' I want to examine the value of argv1'. After my modification, I go into the ghc/ folder and run : 'make'But doing this leads to an error when I try to run the program : ghc-stage2: panic! (the 'impossible' happened) (GHC version 7.11.20150810 for x86_64-unknown-linux): Static flags have not been initialised! Please call GHC.parseStaticFlags early enough. What am I doing wrong ? Omar Mefire,

2 4

Forcing a linking error?
by Erik de Castro Lopo 14 Aug '15

14 Aug '15

Dear ghc-devs, There is a commonly used library which has at least one function that when compiled into a program, requires the threaded run time system. Without the threaded runtime, the program just hangs. One kludgy solution to this problem is to have the function check for Control.Concurrent.rtsSupportsBoundThreads being true and throwing an error if its not. However, it would be much nicer if this could be turned into a link time error. Anyone have any ideas how this might be done? Cheers, Eri -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/

3 2

Re: [GHC] #9868: ghc: panic! Dynamic linker not initialised
by Matthew Pickering 12 Aug '15

12 Aug '15

I can't reproduce this with 7.10.2. On Wed, Aug 12, 2015 at 4:54 PM, GHC <ghc-devs(a)haskell.org> wrote: > #9868: ghc: panic! Dynamic linker not initialised > -------------------------------------+------------------------------------- > Reporter: Jamedjo | Owner: > Type: bug | Status: infoneeded > Priority: normal | Milestone: > Component: Compiler | Version: 7.8.3 > Resolution: | Keywords: > Operating System: MacOS X | Architecture: x86_64 > Type of failure: Compile-time | (amd64) > crash | Test Case: > Blocked By: | Blocking: > Related Tickets: | Differential Revisions: > -------------------------------------+------------------------------------- > Changes (by bgamari): > > * status: new => infoneeded > > > Comment: > > I'm not really sure what we can do with this bug as is as there isn't > enough information here to reproduce the crash. Moreover, it looks two of > the issues reported here are distinct from the panic which apparently > provoked the ticket. > > Could those affected by this see if they can reproduce the issue on GHC > 7.10.2 and if so provide a detailed set of steps to reproduce the issue? > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9868#comment:3> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler

1 0