- ghc-devs - Haskell.org

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

Type checker error messages question
by Jack Bowman 09 Aug '15

09 Aug '15

Hi all, I'm new to the GHC codebase and am looking to contribute. I started trying to implement https://ghc.haskell.org/trac/ghc/ticket/9173 , "better type error messages". I'm having some difficulty and was hoping someone more experienced could point me in the right direction. Part of the proposed change is that the "inferred:" line lists both the expression ("Just 5") and its type ("Maybe a0"). That's good because it's more clear that way. Currently those are in different parts of the error message. The function misMatchMsg (TcErrors.hs) creates the text "couldn't match expected type...". The text "In the second argument of..." is created by funAppCtxt (TcExpr.hs) during type checking. Bringing these together seems tricky. When we're generating a message like "couldn't match expected type..." I don't see how to access the expression text, like the "LHsExpr Name"s available to funAppCtxt. Is there an easy way to get that? We have the constraint and the two types, but I don't think those include this info. It seems fundamental to the error messages that the context ("in the _ argument..., in the expression ...") is built up as *text* while we do type checking, which means it's hard to customize when building the final error message. Please let me know if I'm missing something. There's a lot of type checker state that I might be misunderstanding. Thanks,Jack

2 1

Re: ghc-devs Digest, Vol 144, Issue 13
by Darren Grant 09 Aug '15

09 Aug '15

The Windows Task Force roster is here: https://ghc.haskell.org/trac/ghc/wiki/WindowsTaskForce A couple months ago I was looking into some of the linker issues (one manifestation of which was failure to link in mingw under TH phases as in #10672), but I was sadly unable to make much headway. I'm still interested in cracking this as Windows is my primary development platform, but new leads are required. Eventually, I may just seek a ground-up understanding of linkers in Windows and mingw. If anyone else has leads, please let me know if I can help. Cheers, Darren On Sun, Aug 9, 2015 at 5:00 AM, <ghc-devs-request(a)haskell.org> wrote: > Send ghc-devs mailing list submissions to > ghc-devs(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > or, via email, send a message with subject or body 'help' to > ghc-devs-request(a)haskell.org > > You can reach the person managing the list at > ghc-devs-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ghc-devs digest..." > > > Today's Topics: > > 1. Linking issue on Windows: #10672 (Richard Eisenberg) > 2. Re: Linking issue on Windows: #10672 (John Wiegley) > 3. Type checker error messages question (Jack Bowman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 8 Aug 2015 14:23:31 -0400 > From: Richard Eisenberg <eir(a)cis.upenn.edu> > To: ghc-devs Devs <ghc-devs(a)haskell.org> > Subject: Linking issue on Windows: #10672 > Message-ID: <8839B562-9A83-4137-A0D6-5DC15137C9C6(a)cis.upenn.edu> > Content-Type: text/plain; charset=us-ascii > > Hi devs, > > Bug #10672 was posted two weeks ago and has not received any response. It > concerns linking issues on Windows with Template Haskell. This is very far > out of my depth, but I don't recognize the name of the poster (lukexi), and > so it would be great to let that person know we've received the report and > have at least triaged it. Who are the Windows task force? I can't seem to > find that listed on https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but > perhaps there's a better place to look. > > If you have any idea of what's going on, would you mind at least > commenting on the bug? > > Thanks! > Richard > Template Haskell czar but linking buffoon and Windows ignoramus > > ------------------------------ > > Message: 2 > Date: Sat, 08 Aug 2015 12:35:25 -0700 > From: "John Wiegley" <johnw(a)newartisans.com> > To: Richard Eisenberg <eir(a)cis.upenn.edu> > Cc: ghc-devs Devs <ghc-devs(a)haskell.org> > Subject: Re: Linking issue on Windows: #10672 > Message-ID: <m2d1yxshdu.fsf(a)newartisans.com> > Content-Type: text/plain > > >>>>> Richard Eisenberg <eir(a)cis.upenn.edu> writes: > > > If you have any idea of what's going on, would you mind at least > commenting > > on the bug? > > I would also like to know who knows what about which linking platforms we > support. > > John > > > ------------------------------ > > Message: 3 > Date: Sat, 8 Aug 2015 22:56:00 -0400 > From: Jack Bowman <johnrbowman(a)gmail.com> > To: ghc-devs(a)haskell.org > Subject: Type checker error messages question > Message-ID: > < > CACcVNgUgbw9WLocN7dFM5Wewh8WbG4d81MwNmZQhcSedoSJEVQ(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi all, > I'm new to the GHC codebase and am looking to contribute. I started trying > to implement https://ghc.haskell.org/trac/ghc/ticket/9173 , "better type > error messages". I'm having some difficulty and was hoping someone more > experienced could point me in the right direction. > Part of the proposed change is that the "inferred:" line lists both the > expression ("Just 5") and its type ("Maybe a0"). That's good because it's > more clear that way. Currently those are in different parts of the error > message. The function misMatchMsg (TcErrors.hs) creates the text "couldn't > match expected type...". The text "In the second argument of..." is created > by funAppCtxt (TcExpr.hs) during type checking. Bringing these together > seems tricky. When we're generating a message like "couldn't match expected > type..." I don't see how to access the expression text, like the "LHsExpr > Name"s available to funAppCtxt. Is there an easy way to get that? We have > the constraint and the two types, but I don't think those include this > info. > It seems fundamental to the error messages that the context ("in the _ > argument..., in the expression ...") is built up as *text* while we do type > checking, which means it's hard to customize when building the final error > message. > Please let me know if I'm missing something. There's a lot of type checker > state that I might be misunderstanding. > Thanks,Jack >

1 0

Linking issue on Windows: #10672
by Richard Eisenberg 08 Aug '15

08 Aug '15

Hi devs, Bug #10672 was posted two weeks ago and has not received any response. It concerns linking issues on Windows with Template Haskell. This is very far out of my depth, but I don't recognize the name of the poster (lukexi), and so it would be great to let that person know we've received the report and have at least triaged it. Who are the Windows task force? I can't seem to find that listed on https://ghc.haskell.org/trac/ghc/wiki/TeamGHC, but perhaps there's a better place to look. If you have any idea of what's going on, would you mind at least commenting on the bug? Thanks! Richard Template Haskell czar but linking buffoon and Windows ignoramus

2 1