January 2013 - ghc-devs

Re: Building on android - compiled program segfaults
by Nathan Hüsken 13 Jan '13

13 Jan '13

Mmh, that does not seem to work. (gdb) strace warning: Couldn't determine the static tracepoint marker to probe Static tracepoint 1 at 0x3f0588 On 01/13/2013 12:56 PM, Conrad Parker wrote: > On 11 January 2013 19:36, Nathan Hüsken <nathan.huesken(a)posteo.de> wrote: >> Hi, >> >> I was succesfull in building ghc (pulled from git) to compile for >> arm-linux-androideabi! >> >> Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this >> Main.hs: >> >> main = putStrLn "Hello, World" >> >> I get an executable, which I can run on my android device. Unfortantly >> it segfaults. >> >> Running it with ./Main +RTS -DS gives: >> >> cap 0: initialised >> >> Now I am trying to debug this in gdb. When I try to display the stack >> (which should be in r13 on arm of I understand correctly, I get); >> >> (gdb) p8 $r13 >> 0xbef00a74: 0x0 >> 0xbef00a70: 0x0 >> 0xbef00a6c: 0x3c2e74 >> 0xbef00a68: 0x530350 >> 0xbef00a64: 0x0 >> 0xbef00a60: 0x0 >> 0xbef00a5c: 0x0 >> 0xbef00a58: 0x0 >> >> And now I am clueless. So I tried the good old printf debugging in the >> rts. Using this, I see that it gets before the call to >> scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). >> >> But when I put a printf in the beginning of scheduleWaitThread (in >> Schedule.c) it is not shown. >> >> What else can I do to find out more? > > can you strace it? > > Conrad. >

1 0

Re: Building on android - compiled program segfaults
by Nathan Hüsken 13 Jan '13

13 Jan '13

There is some more success :). When I do an unregisterised build, it works without segfault. On 01/13/2013 11:16 AM, Bernhard Urban wrote: > Hi Nathan, > > On Fri, Jan 11, 2013 at 12:36 PM, Nathan Hüsken > <nathan.huesken(a)posteo.de> wrote: >> I was succesfull in building ghc (pulled from git) to compile for >> arm-linux-androideabi! > > Great news! > Can you describe how you managed to build it and which environment you use? I am on ubuntu 64 bit. I am planing to share the information in a blog post, but I will wait if I (or someone else) gets the registerised build to work. I made a short writedown of the steps it took here: https://github.com/RudolfVonKrugstein/jshaskell-blog/blob/master/android_gh… Regards, Nathan

1 0

make install failing
by Stephen Paul Weber 12 Jan '13

12 Jan '13

I just did a clean build of my cross-compiling GHC with --prefix set in the top-level ./configure call. When I run `make install` I get: "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found make[1]: *** [install_packages] Error 127 make: *** [install] Error 2 Grepping the output for pkg: $ make install 2>&1 | grep pkg "rm" -f "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" ln -s i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg" "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg" --force --global-package-db "/home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/package.conf.d" update rts/package.conf.install /bin/sh: 1: /home/singpolyma/bbndk/host_10_0_9_404/linux/x86/usr/lib/ghc-7.7.20130112/bin/ghc-pkg: not found /bbndk/host_10_0_9_404/linux/x86/usr/bin/i486-pc-nto-qnx8.0.0-ghc-pkg is a symlink to i486-pc-nto-qnx8.0.0-ghc-pkg-7.7.20130112 which does not exist (and I see no attempt to make it exist), and either way it seems that we are installing with a cross-compile prefix, but not invoking with that. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

1 0

RE: Fundeps and type equality
by Simon Peyton-Jones 11 Jan '13

11 Jan '13

Ian: isn't the documentation URL below supposed to be updated nightly from HEAD? I got it from here: http://www.haskell.org/ghc/download#snapshots S From: ghc-tickets-bounces(a)haskell.org [mailto:ghc-tickets-bounces@haskell.org] On Behalf Of Richard Eisenberg Sent: 11 January 2013 14:42 To: Simon Peyton-Jones Cc: glasgow-haskell-bugs(a)haskell.org; Martin Sulzmann; GHC Users Mailing List Subject: Re: Fundeps and type equality That link looks like it points to the manual for the most recent distribution, not HEAD. The edits I put into the manual for the new family instances are not there, for example. Richard On Jan 11, 2013, at 4:56 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: The manual for HEAD is always online here http://www.haskell.org/ghc/dist/current/docs/html/users_guide/type-families… Simon From: Richard Eisenberg [mailto:eir@cis.upenn.edu] Sent: 11 January 2013 03:03 To: Carter Schonwald Cc: Martin Sulzmann; glasgow-haskell-bugs(a)haskell.org<mailto:glasgow-haskell-bugs@haskell.org>; Simon Peyton-Jones; GHC Users Mailing List Subject: Re: Fundeps and type equality Yes, I finished and pushed in December. A description of the design and how to use the feature is here: http://hackage.haskell.org/trac/ghc/wiki/NewAxioms There's also a section (7.7.2.2 to be exact) in the manual, but building the manual from source is not for the faint of heart. Richard On Jan 10, 2013, at 3:14 PM, Carter Schonwald <carter.schonwald(a)gmail.com<mailto:carter.schonwald@gmail.com>> wrote: so the overlapping type families are in HEAD? Awesome! I look forward to finding some time to try them out :) On Thu, Jan 10, 2013 at 1:56 PM, Richard Eisenberg <eir(a)cis.upenn.edu<mailto:eir@cis.upenn.edu>> wrote: For better or worse, the new overlapping type family instances use a different overlapping mechanism than functional dependencies do. Class instances that overlap are chosen among by order of specificity; overlapping instances can be declared in separate modules. Overlapping family instances must be given an explicit order, and those that overlap must all be in the same module. The decision to make these different was to avoid type soundness issues that would arise with overlapping type family instances declared in separate modules. (Ordering a set of family instance equations by specificity, on the other hand, could easily be done within GHC.) So, as yet, we can't fully encode functional dependencies with type families, I don't think. Richard On Jan 2, 2013, at 4:01 PM, Martin Sulzmann <martin.sulzmann.haskell(a)googlemail.com<mailto:martin.sulzmann.haskell@googlemail.com>> wrote: I agree with Iavor that it is fairly straight-forward to extend FC to support FD-style type improvement. In fact, I've formalized such a proof language in a PPDP'06 paper: "Extracting programs from type class proofs" (type improvement comes only at the end) Similar to FC, coercions (proof terms) are used to represent type equations (improvement). Why extend FC? Why not simply use type families to encode FDs (and thus keep FC simple and small). It's been a while, but as far as I remember, the encoding is only problematic in case of the combination of FDs and overlapping instances. Shouldn't this now be fixable given that type family instances can be overlapping? Maybe I'm missing something, guess it's also time to dig out some old notes ... -Martin On Wed, Jan 2, 2013 at 10:04 AM, Simon Peyton-Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). Iavor is quite right It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. Iavor: I don't think it's straightforward, but I'm willing to be educated. By all means start a wiki page to explain how, if you think it is. I do agree that injective type families would be a good thing, and would deal with the main reason that fundeps are sometimes better than type families. A good start would be to begin a wiki page to flesh out the design issues, perhaps linked fromhttp://hackage.haskell.org/trac/ghc/wiki/TypeFunctions The main issues are, I think: * How to express functional dependencies like "fixing the result type and the first argument will fix the second argument" * How to express that idea in the proof language Simon From: glasgow-haskell-bugs-bounces(a)haskell.org<mailto:glasgow-haskell-bugs-bounces@haskell.org> [mailto:glasgow-haskell-bugs-bounces@haskell.org<mailto:glasgow-haskell-bugs-bounces@haskell.org>] On Behalf Of Iavor Diatchki Sent: 26 December 2012 02:48 To: Conal Elliott Cc: glasgow-haskell-bugs(a)haskell.org<mailto:glasgow-haskell-bugs@haskell.org>; GHC Users Mailing List Subject: Re: Fundeps and type equality Hello Conal, GHC implementation of functional dependencies is incomplete: it will use functional dependencies during type inference (i.e., to determine the values of free type variables), but it will not use them in proofs, which is what is needed in examples like the one you posted. The reason some proving is needed is that the compiler needs to figure out that for each instantiation of the type `ta` and `tb` will be the same (which, of course, follows directly from the FD on the class). As far as I understand, the reason that GHC does not construct such proofs is that it can't express them in its internal proof language (System FC). It seems to me that it should be fairly straight-forward to extend FC to support this sort of proof, but I have not been able to convince folks that this is the case. I could elaborate, if there's interest. In the mean time, the way forward would probably be to express the dependency using type families, which I find tends to be more verbose but, at present, is better supported in GHC. Cheers, -Iavor PS: cc-ing the GHC users' list, as there was some talk of closing the ghc-bugs list, but I am not sure if the transition happened yet. On Tue, Dec 25, 2012 at 6:15 PM, Conal Elliott <conal(a)conal.net<mailto:conal@conal.net>> wrote: I ran into a simple falure with functional dependencies (in GHC 7.4.1): > class Foo a ta | a -> ta > > foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool > foo = (==) I expected that the `a -> ta` functional dependency would suffice to prove that `ta ~ tb`, but Pixie/Bug1.hs:9:7: Could not deduce (ta ~ tb) from the context (Foo a ta, Foo a tb, Eq ta) bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool at Pixie/Bug1.hs:9:1-10 `ta' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool at Pixie/Bug1.hs:9:1 `tb' is a rigid type variable bound by the type signature for foo :: (Foo a ta, Foo a tb, Eq ta) => ta -> tb -> Bool at Pixie/Bug1.hs:9:1 Expected type: ta -> tb -> Bool Actual type: ta -> ta -> Bool In the expression: (==) In an equation for `foo': foo = (==) Failed, modules loaded: none. Any insights about what's going wrong here? -- Conal _______________________________________________ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs(a)haskell.org<mailto:Glasgow-haskell-bugs@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users(a)haskell.org<mailto:Glasgow-haskell-users@haskell.org> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 2

Building on android - compiled program segfaults
by Nathan Hüsken 11 Jan '13

11 Jan '13

Hi, I was succesfull in building ghc (pulled from git) to compile for arm-linux-androideabi! Now using "inplace/bin/ghc-stage1 -dcore-lint -debug" I compiler this Main.hs: main = putStrLn "Hello, World" I get an executable, which I can run on my android device. Unfortantly it segfaults. Running it with ./Main +RTS -DS gives: cap 0: initialised Now I am trying to debug this in gdb. When I try to display the stack (which should be in r13 on arm of I understand correctly, I get); (gdb) p8 $r13 0xbef00a74: 0x0 0xbef00a70: 0x0 0xbef00a6c: 0x3c2e74 0xbef00a68: 0x530350 0xbef00a64: 0x0 0xbef00a60: 0x0 0xbef00a5c: 0x0 0xbef00a58: 0x0 And now I am clueless. So I tried the good old printf debugging in the rts. Using this, I see that it gets before the call to scheduleWaitThread in the function rts_evalLazyIO (in RtsAPI.c). But when I put a printf in the beginning of scheduleWaitThread (in Schedule.c) it is not shown. What else can I do to find out more? Thanks! Nathan

3 7

Re: [commit: ghc] master: Make the rule for .hi files depend on the .hs/.lhs files (5cb0880)
by Simon Marlow 11 Jan '13

11 Jan '13

On 10/01/13 19:24, Ian Lynagh wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/5cb088088be8573a01c991421ad88… > >> --------------------------------------------------------------- > > commit 5cb088088be8573a01c991421ad882ce899067db > Author: Ian Lynagh <ian(a)well-typed.com> > Date: Sat Jan 5 18:50:29 2013 +0000 > > Make the rule for .hi files depend on the .hs/.lhs files > > make thought that it could make a .hi file for the C files in > libraries, which was causing problems when using dynamic-too. Are you sure? This rule is *very* delicate (see the comments). Won't this change cause make to think that it can build the .hi file by not doing anything? Cheers, Simon >> --------------------------------------------------------------- > > ghc.mk | 4 ---- > rules/hi-rule.mk | 8 +++++--- > rules/hs-suffix-rules-srcdir.mk | 2 ++ > rules/hs-suffix-rules.mk | 3 +++ > 4 files changed, 10 insertions(+), 7 deletions(-) > > diff --git a/ghc.mk b/ghc.mk > index f4a7a61..d71d8c9 100644 > --- a/ghc.mk > +++ b/ghc.mk > @@ -229,10 +229,6 @@ ifneq "$(CLEANING)" "YES" > include rules/hs-suffix-rules-srcdir.mk > include rules/hs-suffix-rules.mk > include rules/hi-rule.mk > - > -$(foreach way,$(ALL_WAYS),\ > - $(eval $(call hi-rule,$(way)))) > - > include rules/c-suffix-rules.mk > include rules/cmm-suffix-rules.mk > > diff --git a/rules/hi-rule.mk b/rules/hi-rule.mk > index 35baffd..c1e7502 100644 > --- a/rules/hi-rule.mk > +++ b/rules/hi-rule.mk > @@ -62,11 +62,13 @@ > # documentation). An empty command is enough to get GNU make to think > # it has updated %.hi, but without actually spawning a shell to do so. > > -define hi-rule # $1 = way > +define hi-rule # $1 = source directory, $2 = object directory, $3 = way > > -%.$$($1_hisuf) : %.$$($1_osuf) ; > +$2/%.$$($3_hisuf) : $2/%.$$($3_osuf) $1/%.hs ; > +$2/%.$$($3_hisuf) : $2/%.$$($3_osuf) $1/%.lhs ; > > -%.$$($1_way_)hi-boot : %.$$($1_way_)o-boot ; > +$2/%.$$($3_way_)hi-boot : $2/%.$$($3_way_)o-boot $1/%.hs ; > +$2/%.$$($3_way_)hi-boot : $2/%.$$($3_way_)o-boot $1/%.lhs ; > > endef > > diff --git a/rules/hs-suffix-rules-srcdir.mk b/rules/hs-suffix-rules-srcdir.mk > index 94a41d5..776d1ce 100644 > --- a/rules/hs-suffix-rules-srcdir.mk > +++ b/rules/hs-suffix-rules-srcdir.mk > @@ -52,6 +52,8 @@ $1/$2/build/%.$$($3_hcsuf) : $1/$4/%.hs $$(LAX_DEPS_FOLLOW) $$($1_$2_HC_DEP) $$( > $1/$2/build/%.$$($3_hcsuf) : $1/$4/%.lhs $$(LAX_DEPS_FOLLOW) $$($1_$2_HC_DEP) $$($1_$2_PKGDATA_DEP) > $$(call cmd,$1_$2_HC) $$($1_$2_$3_ALL_HC_OPTS) -C $$< -o $$@ > > +$(call hi-rule,$1/$4,$1/$2/build,$3) > + > endif > > # XXX: for some reason these get used in preference to the direct > diff --git a/rules/hs-suffix-rules.mk b/rules/hs-suffix-rules.mk > index 9d54753..9b11e6e 100644 > --- a/rules/hs-suffix-rules.mk > +++ b/rules/hs-suffix-rules.mk > @@ -28,6 +28,9 @@ $1/$2/build/%.$$($3_hcsuf) : $1/$2/build/autogen/%.hs $$(LAX_DEPS_FOLLOW) $$($1_ > $1/$2/build/%.$$($3_osuf) : $1/$2/build/autogen/%.hs $$(LAX_DEPS_FOLLOW) $$($1_$2_HC_DEP) > $$(call cmd,$1_$2_HC) $$($1_$2_$3_ALL_HC_OPTS) -c $$< -o $$@ > > +$(call hi-rule,$1/$2/build,$1/$2/build,$3) > +$(call hi-rule,$1/$2/build/autogen,$1/$2/build,$3) > + > endif > endif > > > > > _______________________________________________ > ghc-commits mailing list > ghc-commits(a)haskell.org > http://www.haskell.org/mailman/listinfo/ghc-commits >

2 2

ASSERT when cross compiling to QNX with Debug enabled
by Nathan Hüsken 10 Jan '13

10 Jan '13

Hey, When I cross compile to arm-unknown-nto-qnx8.0.0eabi and add DDEBUG to GhcStage1HcOpts I get: "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-simple-0.1.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fllvm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./Unsafe/Coerce.hs -o libraries/base/dist-install/build/Unsafe/Coerce.o "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-simple-0.1.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fllvm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./GHC/Int.hs -o libraries/base/dist-install/build/GHC/Int.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130109 for arm-unknown-nto-qnx): ASSERT failed! file compiler/basicTypes/Literal.lhs line 222 2147483648 I do not know if this is fatal, but I would like to have a build with debug symbols ... Regards, Nathan

1 1

ASSERT when cross compiling to QNX with Debug enabled
by Nathan Hüsken 10 Jan '13

10 Jan '13

Hey, When I cross compile to arm-unknown-nto-qnx8.0.0eabi and add DDEBUG to GhcStage1HcOpts I get: "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-simple-0.1.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fllvm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./Unsafe/Coerce.hs -o libraries/base/dist-install/build/Unsafe/Coerce.o "inplace/bin/ghc-stage1" -static -H64m -O0 -fllvm -package-name base-4.7.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.3.1.0 -package integer-simple-0.1.1.0 -package rts-1.0 -package-name base -XHaskell98 -XCPP -O -fllvm -no-user-package-db -rtsopts -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf hi -osuf o -hcsuf hc -c libraries/base/./GHC/Int.hs -o libraries/base/dist-install/build/GHC/Int.o ghc-stage1: panic! (the 'impossible' happened) (GHC version 7.7.20130109 for arm-unknown-nto-qnx): ASSERT failed! file compiler/basicTypes/Literal.lhs line 222 2147483648 I do not know if this is fatal, but I would like to have a build with debug symbols ... Regards, Nathan

1 0