February 2014 - ghc-devs

Re: What does the DWARF information generated by your GHC branch look like?
by Johan Tibell 28 Feb '14

28 Feb '14

On Thu, Feb 27, 2014 at 6:43 PM, Peter Wortmann <scpmw(a)leeds.ac.uk> wrote: > > Johan Tibell wrote: > > I enjoyed reading your paper [1] and I have some questions. > > Thanks! The DWARF patches are currently under review for Trac #3693. Any > feedback would be very appreciated: > https://github.com/scpmw/ghc/commits/profiling-import I haven't had time to look at it all. I added a comment on https://github.com/scpmw/ghc/commit/bbf6f35d8c341c8aadca1a48657084c007837b21 > > will you fill in the .debug_line section so that standard tools like > > "perf report" and gprof can be used on Haskell code? > > Yes, even though from a few quick tests the results of "perf report" > aren't too useful, as source code links are pretty coarse and jump > around a lot - especially for optimised Haskell code. There's the option > to instead annotate with source code links to a generated ".dump-simpl" > file, which might turn out to be more useful. > I think that in general we should be as "standard" (i.e. close to how e.g. GCC uses DWARF) as possible and put extra information in e.g. .debug_ghc. That way we maximize the chance that standard tools will do something sensible. > > Code pointers would be appreciated. > > Is this about how .debug_line information is generated? We take the same > approach as LLVM (and GCC, I think) and simply annotate the assembly > with suitable .file & .loc directives. That way we can leave all the > heavy lifting to the assembler. > > Current patch is here: > https://github.com/scpmw/ghc/commit/c5294576 Makes sense. Thanks. > > * Does your GHC allow DWARF information to be generated without > > actually using any of the RTS (e.g. eventlog) machinery? > > The RTS just serves as a DWARF interpreter for its own executable (+ > libraries) in this, so yes, it's fully independent. On the other hand, > having special code allows us to avoid a few subtleties about Haskell > code that are hard to communicate to standard debugging tools > (especially concerning stack tracing). > Sounds good. As long as it's possible to use this without the RTS/eventlog support I be happy. I have profiling needs (e.g. in unordered-containers) were changes in the <5% are interesting and any extra overhead will skew the results. > > Another way to ask the same question, do you have a ghc -g flag that > > has no implication for the runtime settings? > > Right now -g does not affect the RTS at all. We might want to change > that at some point though so we can get rid of the libdwarf dependency. > That sounds good (the don't affect the RTS part). I didn't understand the libdwarf part. > > * Do you generate DW_TAG_subprogram sections in the .debug_info > > section so that other tools can figure out the name of Haskell > > functions? > > Yes, we are setting the "name" attribute to a suitable Haskell name. > Sadly, at least GDB seems to ignore it and falls back to the symbol > name. I investigated this some time ago, and I think the reason was that > it doesn't recognize the Haskell language ID (which isn't standardized, > obviously). Simply pretending to be C(++) might fix this, but I would be > a bit scared of other side-effects. > Lets try to get our name standardized and pushed into GDB. It's hopefully as simple as sending an email to the GDB devs. Cheers, Johan

1 0

first version of RC2 has problems with lack of dynamic problems at least on the Mac
by George Colpitts 27 Feb '14

27 Feb '14

Hi After installing the first version of RC2 I ran into the following problem cabal install vector Resolving dependencies... Configuring vector-0.10.9.1... ... [ 5 of 19] Compiling Data.Vector.Fusion.Stream.Monadic ( Data/Vector/Fusion/Stream/Monadic.hs, dist/build/Data/Vector/Fusion/Stream/Monadic.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package primitive-0.5.2.1 ... <command line>: can't load .so/.DLL for: libHSprimitive-0.5.2.1.dylib (dlopen(libHSprimitive-0.5.2.1.dylib, 9): image not found) There seems to be a general problem that the install did not produce any dynamic libraries at least on the Mac: ls /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/*/lib /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/cpphs-1.18.2/lib: HScpphs-1.18.2.o Language Text libHScpphs-1.18.2.a libHScpphs-1.18.2_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hashable-1.2.1.0/lib: Data HShashable-1.2.1.0.o libHShashable-1.2.1.0.a libHShashable-1.2.1.0_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/hscolour-1.20.3/lib: HShscolour-1.20.3.o Language libHShscolour-1.20.3.a libHShscolour-1.20.3_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/primitive-0.5.2.1/lib: Control HSprimitive-0.5.2.1.o libHSprimitive-0.5.2.1.a Data include libHSprimitive-0.5.2.1_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/syb-0.4.1/lib: Data Generics HSsyb-0.4.1.o libHSsyb-0.4.1.a libHSsyb-0.4.1_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/text-1.1.0.0/lib: Data HStext-1.1.0.0.o libHStext-1.1.0.0.a libHStext-1.1.0.0_p.a /Users/gcolpitts/Library/Haskell/ghc-7.8.0.20140226/lib/unordered-containers-0.2.3.3/lib: Data libHSunordered-containers-0.2.3.3.a HSunordered-containers-0.2.3.3.o libHSunordered-containers-0.2.3.3_p.a

2 1

RC2 release imminent
by Austin Seipp 27 Feb '14

27 Feb '14

Hello all, Just as a quick update, the RC2 release will be soon. I plan on fixing #8736 and releasing it. #8696 will come shortly with the final release. I'll follow up when a source tarball is available, so Pali and Karel can build binaries. -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

8 17

SPARC: why it's not registerised anymore?
by Karel Gardas 26 Feb '14

26 Feb '14

Folks, just out of curiosity I'm building latest GHC on SPARC/Solaris and I've noted that current GHCs (7.6 and HEAD) are building unregisterised by default. In the history I remember at least some GHC were registerised and GHC source code also (still) contains SPARC NCG so I'm curious what was the reason behind the switch? Any bug still waiting for a fix? Or just code rotted in a way it's not working any more? Thanks! Karel

2 3

would support for kind equalities enable the following example?
by Carter Schonwald 25 Feb '14

25 Feb '14

Hey all, I've a use case in my code where It looks like it might be an example of something that won't compile until we have type level GADTs I'm essentially writing a vector api that allows certain args to be mutable, pure or "dont care". (dont care = that they're treated as being immutable). I'm using GADTs to model this. (using GADTs rather than type classes partly because I want to make sure type inference works out nicely, and partly to see how far i can go while not adding any new type classes) data Eff :: * -> * where Pure :: Eff () Mut :: s -> Eff s data EVector :: * -> * -> * where PureVector :: S.Vector el -> EVector Pure el MutVector :: SM.MVector s el -> EVector (Mut s) el the above doesn't work because DataKinds only works at kind * currently, however i can defunctionalize it to the following (while making it a tad less pretty) and it then works data Eff = Pure | Mut data EVector :: Eff -> * -> * -> * where PureVector :: S.Vector el -> EVector Pure () el MutVector :: SM.MVector s el -> EVector Mut s el am i correct in thinking that the first example *should* be possible once we have fancier kind machinery (kind equalities and type level GADTs?)? I suspect I'll be hitting *A LOT* more examples like the above, and if theres any ways I can help push this along on the research or engineering side, I please tell me :) thanks! -Carter

2 4

Pretty-printing of type variables (Help needed for #8776)
by Dr. ERDI Gergo 25 Feb '14

25 Feb '14

Hi, Ticket #8776 (https://ghc.haskell.org/trac/ghc/ticket/8776) is about the output formatting of pattern synonym type signatures. With -dppr-debug, the problematic signature looks like this: (base:GHC.Num.Num{tc 2b} t{tv aQa} [sk], ghc-prim:GHC.Classes.Eq{tc 23} t{tv aQb} [sk]) => main:Main.P{d rs2} :: main:Main.A{tc rpC} t{tv aQa} [sk] t1{tv aQb} [sk] The problem is that the two type variables occuring in the provided context both have "t" as their user-visible name; even though the second one is projected as "t1" in the tau type on the right-hand side. The code to generate this output is in HsBinds.ppr_sig, using pprPatSynSig which just adds the "pattern" keyword and the separating "=>" symbols etc: ppr_sig (PatSynSig name arg_tys ty prov req) = pprPatSynSig (unLoc name) False args (ppr ty) (pprCtx prov) (pprCtx req) where args = fmap ppr arg_tys pprCtx lctx = case unLoc lctx of [] -> Nothing ctx -> Just (pprHsContextNoArrow ctx) My guess is that the problem is 'pprHsContextNoArrow' projects individual constraints one-by-one and so doesn't notice the name clash on 't' between the two constraints in the example; whereas 'ppr ty' walks the whole right-hand tau type and thus has the opportunity to maintain a set of type variable names used. My question is, where is that logic, and how can I use that in this instance? My hope is to be shown a design where I can run 'ppr ty', 'pprCtx prov' and 'pprCtx req' in the same "naming environment" (I hope such a thing exists) so that they use a consistent naming scheme. This looks like a problem that must have popped up at a lot of places in GHC already and must have an idiomatic solution. Thanks, Gergo

1 0

cpphs bug
by Roman Cheplyaka 24 Feb '14

24 Feb '14

Hi Malcolm, This appears to be a cpphs bug. For the following code #define x (1 == 1) #if x YES #else NO #endif cpphs 1.18.1 prints NO, while the expected output (and the output GNU cpp produces) is YES. If parentheses around 1 == 1 are removed, or if x is inlined manually, then cpphs correctly prints YES. This affects GHC 7.8 users in a serious way: GHC 7.8 uses cpphs, and the above code is a simplified version of macros generated by cabal. For this reason, for instance, type-eq 0.4.1 cannot be build by GHC 7.8 RC1, despite the proper CPP guards. Roman

3 4

Change in rendering of [] in GADTs
by Mateusz Kowalczyk 22 Feb '14

22 Feb '14

While running Haddock tests today, we noticed that the output for a test with GADTs changed. See the test file in the bottom. We used to render ‘Nil :: Pattern '[]’ as ‘Pattern []’ but it now renders as ‘Pattern `[]`’. The change happened within last 2 days and I'm guessing it's d3af9807ca8a1db0bc9298ea50895ee9df55edb7 that made the change. Should this be something that we fix on Haddock end or should it be left with the new rendering? I'm unsure whether the previous rendering wasn't better or not. The Haddock test suite is not ran as part of GHC validate process so it the failure slipped by. The file is: {-# LANGUAGE DataKinds #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE KindSignatures #-} {-# LANGUAGE TypeOperators #-} module AdvanceTypes where data Pattern :: [*] -> * where Nil :: Pattern '[] Cons :: Maybe h -> Pattern t -> Pattern (h ': t) -- Mateusz K.

1 0

32-bit Linux perf failures
by Mateusz Kowalczyk 20 Feb '14

20 Feb '14

Greetings, I just ran validate with current HEAD (2b34947b60069e51abfcada9c45a6d7b590f5a2b) and I have quite a few perf failures. Perhaps these need tweaking? I know that 32-bit numbers were neglected in the past. The Haddock numbers have been complaining for a few weeks now but I think everything else is fairly new. Here is the end of the log: Unexpected results from: TEST="T876 T7954 T8766 T1969 T5631 T783 T3294 haddock.Cabal haddock.compiler haddock.base T3924" OVERALL SUMMARY for test run started at Thu Feb 20 00:54:28 2014 GMT 0:18:11 spent to go through 3903 total tests, which gave rise to 15265 test cases, of which 11699 were skipped 28 had missing libraries 3469 expected passes 58 expected failures 3 caused framework failures 0 unexpected passes 11 unexpected failures Unexpected failures: ../../libraries/base/tests T8766 [stat too good] (normal) callarity/perf T3924 [stat too good] (normal) perf/compiler T1969 [stat too good] (normal) perf/compiler T3294 [stat too good] (normal) perf/compiler T5631 [stat too good] (normal) perf/compiler T783 [stat too good] (normal) perf/haddock haddock.Cabal [stat too good] (normal) perf/haddock haddock.base [stat not good enough] (normal) perf/haddock haddock.compiler [stat too good] (normal) perf/should_run T7954 [stat too good] (normal) perf/should_run T876 [stat too good] (normal) -- Mateusz K.

3 3

Re: [commit: ghc] master: Update to primitive-0.5.2.1 (47d725f)
by Karel Gardas 20 Feb '14

20 Feb '14

Herbert, thanks for merging this, but this is somehow not working for me. I see this patch in ghc repo after ./sync-all pull, but my libraries/primitive is still on 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b commit from November 2013 Is there anything special I need to do in order to update git submodules? Thanks! Karel On 02/19/14 11:28 PM, git(a)git.haskell.org wrote: > Repository : ssh://git@git.haskell.org/ghc > > On branch : master > Link : http://ghc.haskell.org/trac/ghc/changeset/47d725f29376fa1be726e913cdf3dd69c… > >> --------------------------------------------------------------- > > commit 47d725f29376fa1be726e913cdf3dd69c46327c2 > Author: Herbert Valerio Riedel<hvr(a)gnu.org> > Date: Wed Feb 19 23:26:30 2014 +0100 > > Update to primitive-0.5.2.1 > > This contains a compile-fix for Solaris > > Signed-off-by: Herbert Valerio Riedel<hvr(a)gnu.org> > > >> --------------------------------------------------------------- > > 47d725f29376fa1be726e913cdf3dd69c46327c2 > libraries/primitive | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libraries/primitive b/libraries/primitive > index 5ae8fbb..be63ee1 160000 > --- a/libraries/primitive > +++ b/libraries/primitive > @@ -1 +1 @@ > -Subproject commit 5ae8fbb8131ccc934cadd29cc1d17298cfdaef4b > +Subproject commit be63ee15d961dc1b08bc8853b9ff97708551ef36 > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 1