stg_ap_v_ret porting crash: solved?
On Sat, 6 Sep 2003, Donald Bruce Stewart wrote:
simonmar:
I was a bit too soon reporting the sparc-sun-solaris2, two attempts have died with stg_ap_v_ret. Same result sparc-*-openbsd.
Also with mips-sgi-irix65 . An attempt died with stg_ap_v_ret .
I'm trying to follow Ian's steps....but please, report any change you can make on the doc "Bootstraping GHC from hc-files".
Aha! I *think* I've figured out what's going wrong. The stg_ap_v_ret failure is caused by info tables being generated for the wrong endianness. This isn't supposed to happen, because we should be cross-compiling for the correct endianness, but I'm guessing that the config.h copied over from the target to the host machine has been overwritten during the build process with an incorrect one. Try this: before doing 'cd H/ghc && make boot && make' on the host machine, do 'touch ghc/includes/config.h'. Check after the build that this file hasn't been overwritten. Cheers, Simon
simonmar:
On Sat, 6 Sep 2003, Donald Bruce Stewart wrote:
simonmar:
I was a bit too soon reporting the sparc-sun-solaris2, two attempts have died with stg_ap_v_ret. Same result sparc-*-openbsd.
Also with mips-sgi-irix65 . An attempt died with stg_ap_v_ret .
I'm trying to follow Ian's steps....but please, report any change you can make on the doc "Bootstraping GHC from hc-files".
Aha! I *think* I've figured out what's going wrong.
The stg_ap_v_ret failure is caused by info tables being generated for the wrong endianness. This isn't supposed to happen, because we should be cross-compiling for the correct endianness, but I'm guessing that the config.h copied over from the target to the host machine has been overwritten during the build process with an incorrect one.
Try this: before doing 'cd H/ghc && make boot && make' on the host machine, do 'touch ghc/includes/config.h'. Check after the build that this file hasn't been overwritten.
Looks like that was it! I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously. So get porting :) -- Don
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote:
Looks like that was it!
I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously.
Is that using the instructions in the users guide and without having to copy .hi files over? Thanks Ian
igloo:
On Wed, Sep 10, 2003 at 07:57:33AM +1000, Donald Bruce Stewart wrote:
Looks like that was it!
I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously.
Is that using the instructions in the users guide and without having to copy .hi files over?
Following the new guide, and the new distrib/hc-build, with the fix to .hc file generation on the host that Simon sorted out yesterday. This generated a working sparc binary. That compiler in turn is recompiling the libraries and generating new .hi files. So, no, I don't have to copy the .hi files over, though at the cost of waiting for the .hi files to be regenerated. -- Don
On Wed, Sep 10, 2003 at 08:31:40AM +1000, Donald Bruce Stewart wrote:
Following the new guide, and the new distrib/hc-build, with the fix to .hc file generation on the host that Simon sorted out yesterday.
This generated a working sparc binary. That compiler in turn is recompiling the libraries and generating new .hi files.
Looks like it's working here too :-) Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like it is working fine, although I am getting ghc-6.0.1(9371): unaligned access to 0x4000000001e6177a, ip=0x4000000000dd46c1 when compiling even hello world with optimisation. The result seems to work fine though. Is this expected? Or maybe I missed a patch? [Added Matt Chapman to the CC list] Things aren't so easy with alpha as gcc rejects the -mieee flag when GHC calls gcc for -cpp'ing. I fear a nasty hacky wrapper may be in order. Ian
igloo:
On Wed, Sep 10, 2003 at 08:31:40AM +1000, Donald Bruce Stewart wrote:
Following the new guide, and the new distrib/hc-build, with the fix to .hc file generation on the host that Simon sorted out yesterday.
This generated a working sparc binary. That compiler in turn is recompiling the libraries and generating new .hi files.
Looks like it's working here too :-)
The sparc isn't entirely well-behaved. The unregisterised compiler seems fine, but the first go at building a registerised GHC built a stage1 compiler that "couldn't allocate memory". However, I was being ambitious and had turned on everything: nativeGen, ghci, regs, tail calls etc. I'm being more cautious second time around. I'm having a go at alpha (osf3) too, I'll let you know. As an aside: I'll post bin-dists when registersied builds work. -- Don
On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote:
Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like it is working fine, although I am getting
ghc-6.0.1(9371): unaligned access to 0x4000000001e6177a, ip=0x4000000000dd46c1
when compiling even hello world with optimisation. The result seems to work fine though. Is this expected? Or maybe I missed a patch?
Hmm, no, I don't get any unaligned accesses. My tree is a few months old though, I will update and check. Matt
On Thu, Sep 11, 2003 at 02:21:29PM +1000, Matt Chapman wrote:
On Thu, Sep 11, 2003 at 02:06:57AM +0100, Ian Lynagh wrote:
Bootstrapping IA64 from x86 (with numerous patches from CVS) looks like it is working fine, although I am getting
ghc-6.0.1(9371): unaligned access to 0x4000000001e6177a, ip=0x4000000000dd46c1
when compiling even hello world with optimisation. The result seems to work fine though. Is this expected? Or maybe I missed a patch?
Hmm, no, I don't get any unaligned accesses. My tree is a few months old though, I will update and check.
I'm not using CVS, I'm using 6.0.1 with the patch at http://merulo.debian.org/~igloo/patch I'm not really too worried about it as it seems to work regardless, and will presumably become fixed when 6.2 is released. Thanks Ian
dons:
simonmar:
Aha! I *think* I've figured out what's going wrong.
The stg_ap_v_ret failure is caused by info tables being generated for the wrong endianness. This isn't supposed to happen, because we should be cross-compiling for the correct endianness, but I'm guessing that the config.h copied over from the target to the host machine has been overwritten during the build process with an incorrect one.
Try this: before doing 'cd H/ghc && make boot && make' on the host machine, do 'touch ghc/includes/config.h'. Check after the build that this file hasn't been overwritten.
Looks like that was it!
I've just built a working unreg compiler on sparc-unknown-openbsd, which I have not been able to do previously.
$ uname -msr OpenBSD 3.3 sparc $ cat > test.hs import System.Info main = print System.Info.arch >> print System.Info.os $ /usr/obj/ports/ghc-6.0.1/ghc-6.0.1/ghc/compiler/ghc-inplace test.hs $ ./a.out "sparc" "openbsd" -- Don :D
participants (4)
-
dons＠cse.unsw.edu.au -
Ian Lynagh -
Matt Chapman -
Simon Marlow