RE: stg_ap_v_ret porting crash: solved?
On Fri, 26 Sep 2003, Rafael Martinez Torres wrote:
>
> I enabled the flags -g
>
Sorry , the previous mail was incomplete. "send" button fired.
GhcRtsHcOpts= -g -optc-DDEBUG
GhcRtsCcOpts= -g
This is my session with gdb , ghc-6.0.1 and mips-sgi-irix65.
I thinks this has nothing to do with the gmp library, but with
StgPrimFloat.c , line 250
DEbugging with gdb on a multithread RTS seems not easy . When the program
crash - I ask - is there any thread other than evaluator one present
at RTS ?
I don't understand very much on RTS internals, but, I guess a simple
"Hello World" thread may not deal with "decodeFloat operations"
May be the compiler gcc-3.0 is faulty for big binaries, due to MULTIGOT
linker, as gcc-2.95 was , and pointers are out of control. I will try
gcc-3.2 then ..
Cheers.
bash-2.05a$ !gdb
gdb ghc/compiler/stage1/ghc-6.0.1
(gdb) set args "-B./" -"hello.hs"
(gdb) break main
Breakpoint 1 at 0x1155242c: file Main.c, line 56.
(gdb) run
Starting program:
/scratch/users/eden/6.0.1/ghc-6.0.1-mips/ghc/compiler/stage1/ghc-6.0.1 "-B./"
"hello.hs"
Breakpoint 1, main (argc=3, argv=0x7fff2e84) at Main.c:56
56 startupHaskell(argc,argv,__stginit_Main);
(gdb) n
108 status = rts_mainLazyIO((HaskellObj)mainIO_closure, NULL);
(gdb) s
rts_mainLazyIO (p=0x116b3620, ret=0x0) at SchedAPI.h:54
54 createIOThread(nat stack_size, StgClosure *closure) {
(gdb) n
59t = createThread(stack_size);
..
..
..
428 scheduleThread(tso);
(gdb) n
429 return waitThread(tso, ret);
(gdb) n
waitThread (tso=0x41c, ret=0x116b3620) at Schedule.c:2276
2276{
(gdb) n
2280 m = stgMallocBytes(sizeof(StgMainThread), "waitThread");
(gdb) n
2281 m->tso = tso;
(gdb) n
..
..
..
(gdb) n
2291 main_threads = m;
(gdb) n
2297 stat = waitThread_(m);
(gdb) n
0x1153c0e8 in waitThread ()
Current language: auto; currently asm
(gdb) s
Single stepping until exit from function waitThread,
which has no line number information.
0x1153b164 in updateStablePtrTable ()
(gdb) n
Single stepping until exit from function updateStablePtrTable,
which has no line number information.
Program received signal SIGSEGV, Segmentation fault.
__decodeFloat (man=0x7fff2d00, exp=0x7fff2d10, flt=66.641) at StgPrimFloat.c:250
250 if (sign < 0)
Current language: auto; currently c
(gdb) quit
The program is running. Exit anyway? (y or n) y
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> Numerous additions to configure/configure.in. I can add these
> in CVS, but I'm not sure if I should add
>
> +s390-ibm-linux*)
> + HostPlatform=s390-ibm-linux
> + TargetPlatform=s390-ibm-linux #hack
> + BuildPlatform=s390-ibm-linux #hack
> +HostPlatform_CPP='s390_ibm_linux'
> +HostArch_CPP='s390'
> +HostVendor_CPP='ibm'
> +HostOS_CPP='linux'
> +;;
>
> as it is or with unknown instead of ibm?
Not a big deal, I'll leave this up to you. I don't think we ever
discriminate based on the vendor.
> alpha:
>
> --- ghc6-6.0.1.orig/ghc/includes/Stg.h
> +++ ghc6-6.0.1/ghc/includes/Stg.h
> @@ -33,6 +33,8 @@
> # endif
> #endif
>
> +#include "TailCalls.h"
> +
> /* Configuration */
> #include "config.h"
>
> @@ -186,7 +188,6 @@
> #include "SMP.h"
> #include "MachRegs.h"
> #include "Regs.h"
> -#include "TailCalls.h"
> #include "Block.h"
>
> /* RTS public interface */
>
>
> --- ghc6-6.0.1.orig/ghc/includes/TailCalls.h
> +++ ghc6-6.0.1/ghc/includes/TailCalls.h
> @@ -83,7 +83,9 @@
>
> #ifdef alpha_TARGET_ARCH
>
> +#ifdef IN_STG_CODE
> register void *_procedure __asm__("$27");
> +#endif
>
> #define JMP_(cont) \
> do { _procedure = (void *)(cont); \
I'm a bit suspicious about taking a whole register globally just to do
tailcalls. Someone needs to investigate this.
>
> alpha and hppa (probably):
>
> --- ghc6-6.0.1.orig/ghc/includes/PrimOps.h
> +++ ghc6-6.0.1/ghc/includes/PrimOps.h
> @@ -254,7 +254,7 @@
> EXTFUN_RTS(catchzh_fast);
> EXTFUN_RTS(raisezh_fast);
>
> -extern void stg_exit(I_ n) __attribute__ ((noreturn));
> +extern void stg_exit(int n) __attribute__ ((noreturn));
This has been fixed in the HEAD.
The other patches look fine: commit away, I'll merge into 6.2.
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> 1.- OK. The "distrib/hc-build" migth not handle the > dependencies soundly. What do you mean here? Could you elaborate? > Now I build on the target T as in the host H: > > cd hslibs/ && gmake boot && gmake > cd ghc && gmake boot && gmake > > The "touch config.h" patch seems to solve the stg_ap_v_ret bug... > > 2.- Now the problem seems to be another one: > > bash-2.05$ ghc/compiler/ghc-inplace hello.hs > > crash, and tracing the core it seems a problem having to do with gmp > software: > > bash-2.05a$ gdb ghc-6.0.1 core > > # 0x1153a208 in __decodeFloat () > > if I apply the "-v" flag, then > > bash-2.05$ ghc/compiler/ghc-inplace -v hello.hs > bash-2.05a$ gdb ghc-6.0.1 core > > # 0x11554ae4 in __gmpn_tdiv_qr / ( qp=0x454ed518 ...) > > Any idea ? Adding -v shouldn't make any difference! Try using a debugging version of the RTS (see mk/config.mk for instructions). Is the build attempting to use an already-installed copy of GMP, or is it building the one in the tree? > 3) Simon M. : For the time beeing this is the patch you can integrate > safely into the CVS repository . I have read-only > permissions. There is no doubt on it. Thanks. I noticed that this was the same as the Solaris case, so I merged the two. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
On Fri, 12 Sep 2003, Simon Marlow wrote:
> > --
> > ../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package
> > > /usr/users/eden/scratch/ghc-6.0.1/ghc/driver/package.conf.inpl
> > ace: parse error in package config file
> > gmake[1]: *** [../../ghc/driver/stamp-pkg-conf-base] Error 1
> > gmake: *** [boot] Error 1
>
> Have you done 'make boot' in ghc/driver?
>
mips-sgi-irix65:
1.- OK. The "distrib/hc-build" migth not handle the dependencies soundly.
Now I build on the target T as in the host H:
cd hslibs/ && gmake boot && gmake
cd ghc && gmake boot && gmake
The "touch config.h" patch seems to solve the stg_ap_v_ret bug...
2.- Now the problem seems to be another one:
bash-2.05$ ghc/compiler/ghc-inplace hello.hs
crash, and tracing the core it seems a problem having to do with gmp
software:
bash-2.05a$ gdb ghc-6.0.1 core
# 0x1153a208 in __decodeFloat ()
if I apply the "-v" flag, then
bash-2.05$ ghc/compiler/ghc-inplace -v hello.hs
bash-2.05a$ gdb ghc-6.0.1 core
# 0x11554ae4 in __gmpn_tdiv_qr / ( qp=0x454ed518 ...)
Any idea ?
3) Simon M. : For the time beeing this is the patch you can integrate
safely into the CVS repository . I have read-only permissions. There is no
doubt on it.--- MBlock.c.ori2003-09-18 09:42:10.0 +0200
+++ MBlock.c2003-09-18 09:42:44.0 +0200
@@ -97,6 +97,12 @@
ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
close(fd);
}
+#elif irix_TARGET_OS
+{
+ int fd = open("/dev/zero",O_RDONLY);
+ ret = mmap(addr, size, PROT_READ | PROT_WRITE, MAP_PRIVATE, fd, 0);
+ close(fd);
+}
#elif hpux_TARGET_OS
ret = mmap(addr, size, PROT_READ | PROT_WRITE,
MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Wed, Sep 17, 2003 at 05:14:36PM +0100, Ian Lynagh wrote: > > alpha: > > --- ghc6-6.0.1.orig/ghc/includes/Stg.h > +++ ghc6-6.0.1/ghc/includes/Stg.h > @@ -33,6 +33,8 @@ > # endif > #endif > > +#include "TailCalls.h" > + > /* Configuration */ > #include "config.h" Ooops, TailCalls.h wants to be below config.h or registerised builds fail with JMP_ and friends being undefined symbols. Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Mon, Sep 15, 2003 at 03:18:43PM +0100, Simon Marlow wrote:
>
> > Am I right in thinking that by just putting
> >
> > GhcUnregisterised=YES
> > SplitObjs=NO
> >
> > in mk/build.mk every time you build GHC it ought to not only work on
> > arches with bit-rotted mangler support but also those with none
> > attempted? Where work means compiles the same set of programs, but the
> > result (as well as the compilation) will be slower?
>
> Yes, with the caveat that this applies only to the the code *generated*
> by the GHC you're building.
Ah, and also no GHCi or TH on Linux unless you are x86, sparc or IA64.
The GHCi section at the bottom of
http://www.haskell.org/ghc/docs/latest/html/building/sec-porting-ghc.html
looks like it might be a bit optimistic to me. A case for
"switch (ehdr->e_machine)" must be added at least, and it looks as
though some other tweaking and handling of relocations (I guess the ones
in there are the ones that it belched on during porting?) is generally
necessary.
> Sure, shipping an unregisterised port is completely acceptable.
OK, I uploaded s390, hppa and alpha unregisterised for Debian unstable
earlier today, with ppc to follow shortly I hope (x86, sparc and ia64
are already there registerised).
I needed to apply the following patches to get them to build (this is
largely to files that only matter for registerised building, but it was
easier to fix them than hack the Makefiles):
Numerous additions to configure/configure.in. I can add these in CVS, but
I'm not sure if I should add
+s390-ibm-linux*)
+ HostPlatform=s390-ibm-linux
+ TargetPlatform=s390-ibm-linux #hack
+ BuildPlatform=s390-ibm-linux #hack
+HostPlatform_CPP='s390_ibm_linux'
+HostArch_CPP='s390'
+HostVendor_CPP='ibm'
+HostOS_CPP='linux'
+;;
as it is or with unknown instead of ibm?
powerpc:
--- ghc6-6.0.1.orig/ghc/compiler/nativeGen/MachCode.lhs
+++ ghc6-6.0.1/ghc/compiler/nativeGen/MachCode.lhs
@@ -41,7 +41,7 @@
NatM, thenNat, returnNat, mapNat,
mapAndUnzipNat, mapAccumLNat,
getDeltaNat, setDeltaNat, getUniqueNat,
- IF_OS_darwin(addImportNat COMMA,)
+ IF_ARCH_powerpc(addImportNat COMMA,)
ncgPrimopMoan,
ncg_target_is_32bit
)
[ addImportNat is later used in a #if powerpc_TARGET_ARCH - I don't know
which is actually right, but as long as it compiles it doesn't matter
for an unreg build ]
alpha:
--- ghc6-6.0.1.orig/ghc/includes/Stg.h
+++ ghc6-6.0.1/ghc/includes/Stg.h
@@ -33,6 +33,8 @@
# endif
#endif
+#include "TailCalls.h"
+
/* Configuration */
#include "config.h"
@@ -186,7 +188,6 @@
#include "SMP.h"
#include "MachRegs.h"
#include "Regs.h"
-#include "TailCalls.h"
#include "Block.h"
/* RTS public interface */
--- ghc6-6.0.1.orig/ghc/includes/TailCalls.h
+++ ghc6-6.0.1/ghc/includes/TailCalls.h
@@ -83,7 +83,9 @@
#ifdef alpha_TARGET_ARCH
+#ifdef IN_STG_CODE
register void *_procedure __asm__("$27");
+#endif
#define JMP_(cont) \
do { _procedure = (void *)(cont); \
--- ghc6-6.0.1.orig/ghc/rts/Adjustor.c
+++ ghc6-6.0.1/ghc/rts/Adjustor.c
@@ -73,7 +73,7 @@
#if defined(alpha_TARGET_ARCH)
/* To get the definition of PAL_imb: */
-#include
+#include
#endif
#if defined(ia64_TARGET_ARCH)
[ Don't know if this would break other OSes as it stands - could ifdef
it ]
--- ghc6-6.0.1.orig/ghc/rts/Signals.c
+++ ghc6-6.0.1/ghc/rts/Signals.c
@@ -19,7 +19,7 @@
#include "StablePriv.h"
#ifdef alpha_TARGET_ARCH
-# include
+# include
#endif
#ifdef HAVE_UNISTD_H
[ As above ]
hppa:
--- ghc6-6.0.1.orig/libraries/OpenGL/Makefile
+++ ghc6-6.0.1/libraries/OpenGL/Makefile
@@ -26,6 +26,10 @@
SRC_HC_OPTS += -DCALLCONV=ccall
endif
+ifeq "$(hppa_TARGET_ARCH)" "1"
+SRC_HC_OPTS += -optc-mbig-switch
+endif
+
SRC_HADDOCK_OPTS += -t "HOpenGL Libraries (OpenGL package)" -p prologue.txt
# yeuch, have to get GL_CFLAGS & GL_LIBS in through CPP to package.conf.in
[ this due to a compile failing with
../../ghc/compiler/ghc-inplace -H16m -O -Wall -fffi -Iinclude '-#include "HsOpenGL.h"'
-cpp -I/usr/X11R6/include -DCALLCONV=ccall -package-name OpenGL -O -Rghc-timing
-package base -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c
Graphics/Rendering/OpenGL/GL/QueryUtils.hs -o
Graphics/Rendering/OpenGL/GL/QueryUtils.p_o -ohi
Graphics/Rendering/OpenGL/GL/QueryUtils.p_hi
/tmp/ghc2550.s: Assembler messages:
/tmp/ghc2550.s:46535: Error: Field out of range [-262144..262143] (262648).
/tmp/ghc2550.s:46538: Error: Field out of range [-262144..262143] (263424).
[more of the same]
It need only apply to this file and any other affected, but I don't
know if there's an easy way to do that ]
alpha and hppa (probably):
--- ghc6-6.0.1.orig/ghc/includes/PrimOps.h
+++ ghc6-6.0.1/ghc/includes/PrimOps.h
@@ -254,7 +254,7 @@
RE: stg_ap_v_ret porting crash: solved?
> > What are the binary sizes like? > > magdcalc is > > 2730251 (reg) > 7697141 (unreg) > > before stripping and > > 1375696 (reg) > 4771196 (unreg) > > after. A lot of that difference is due to the absence of SplitObjs on the unregisterised build, so don't worry too much. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Mon, Sep 15, 2003 at 03:18:43PM +0100, Simon Marlow wrote: > > > Starting with a reg compiler producing reg code and iterating > > a standard > > configure/make/make install with 6.0.1 gives these numbers on x86: > > > > 70m5.850s > > 86m27.550s > > 86m26.350s > > > > so it looks like this is about 25% slower, although I don't know how > > much it will vary by architecture. This isn't purely testing GHC of > > course, but I think it's probably pretty close. > > Interesting. Bear in mind that a lot of the time is spent in GCC, and Ah, I hadn't thought about that, I had only considered the cases where gcc was explicitly used to compile C sources. > that is going to be roughly the same for registerised vs. > unregisterised, so overall compile times don't look much different. > However, I think you'll find that ordinary Haskell programs will vary by > about a factor of 2 in performance between registerised & unregisterised > (last time I checked was a few years ago, though). Looks like it hasn't changed then - MAG's testsuite with some of MAG's optimisations removed takes 5m55.710s vs 12m35.560s (compile times were 2m46.870s vs 3m18.610s). > What are the binary sizes like? magdcalc is 2730251 (reg) 7697141 (unreg) before stripping and 1375696 (reg) 4771196 (unreg) after. Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> # I ^C it after a little while: > > Program received signal SIGINT, Interrupt. > 0x1212c62b0 in StgRun () at StgCRun.c:6 > 6* STG-to-C glue. > > > So it stalls or loops (it sits at 98% of cpu) on entry to stg_init(). > > More info will have to wait until I try a debug build. Try with a debugging RTS, and use 'stepi' rather than 'step' when in Haskell code (everything from StgRun onwards), because the debugger won't have any line number info. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> Am I right in thinking that by just putting > > GhcUnregisterised=YES > SplitObjs=NO > > in mk/build.mk every time you build GHC it ought to not only work on > arches with bit-rotted mangler support but also those with none > attempted? Where work means compiles the same set of programs, but the > result (as well as the compilation) will be slower? Yes, with the caveat that this applies only to the the code *generated* by the GHC you're building. > Starting with a reg compiler producing reg code and iterating > a standard > configure/make/make install with 6.0.1 gives these numbers on x86: > > 70m5.850s > 86m27.550s > 86m26.350s > > so it looks like this is about 25% slower, although I don't know how > much it will vary by architecture. This isn't purely testing GHC of > course, but I think it's probably pretty close. Interesting. Bear in mind that a lot of the time is spent in GCC, and that is going to be roughly the same for registerised vs. unregisterised, so overall compile times don't look much different. However, I think you'll find that ordinary Haskell programs will vary by about a factor of 2 in performance between registerised & unregisterised (last time I checked was a few years ago, though). What are the binary sizes like? > This seems better than no GHC at all for unsupported arch/OS > combinations, and I unfortunately don't have the time to learn the > details of what needs to be done and all the assembly languages and > calling conventions that Debian supports. > > It would also mean that anyone who does want to try to get it working > registerised on an arch could skip the cross-porting stage. Sure, shipping an unregisterised port is completely acceptable. > Incidentally, it looks to me like the comment > > # NOTE: this is not the same as building the compiler itself > # unregisterised. That's done by either (a) bootstrapping with a > # compiler that was built with GhcUnregisterised=YES, or (b) > # bootstrapping with a compiler that has way 'u' libraries, and the > # flag '-unreg' is added to GhcHcOpts above. > > about GhcUnregisterised in mk/config.mk is outdated given the 2-stage > building process that is now the default? Hmm, I should update that comment. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Fri, Sep 12, 2003 at 10:59:05AM +0100, Simon Marlow wrote: > > Looks like you need some mangler support now... Am I right in thinking that by just putting GhcUnregisterised=YES SplitObjs=NO in mk/build.mk every time you build GHC it ought to not only work on arches with bit-rotted mangler support but also those with none attempted? Where work means compiles the same set of programs, but the result (as well as the compilation) will be slower? Starting with a reg compiler producing reg code and iterating a standard configure/make/make install with 6.0.1 gives these numbers on x86: 70m5.850s 86m27.550s 86m26.350s so it looks like this is about 25% slower, although I don't know how much it will vary by architecture. This isn't purely testing GHC of course, but I think it's probably pretty close. This seems better than no GHC at all for unsupported arch/OS combinations, and I unfortunately don't have the time to learn the details of what needs to be done and all the assembly languages and calling conventions that Debian supports. It would also mean that anyone who does want to try to get it working registerised on an arch could skip the cross-porting stage. Incidentally, it looks to me like the comment # NOTE: this is not the same as building the compiler itself # unregisterised. That's done by either (a) bootstrapping with a # compiler that was built with GhcUnregisterised=YES, or (b) # bootstrapping with a compiler that has way 'u' libraries, and the # flag '-unreg' is added to GhcHcOpts above. about GhcUnregisterised in mk/config.mk is outdated given the 2-stage building process that is now the default? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
dons: > I got another (loopy) compile on alpha-dec-osf3 that went through > cleanly, with the following fixes: > [..] > > And then everything went though, to the re-configure part of > hc-build, but the ghc-inplace seems to go into an infinite loop > on invocation. It won't produce output even with invalid command > line flags. It just sits and spins for a few minutes, and then I > have to kill it. A quick gdb session on stage1/ghc-6.0.1 on the alpha-dec-osf3: (gdb) run # ^C it after a little while: Program received signal SIGINT, Interrupt. 0x1212c62c4 in StgRun () at StgCRun.c:6 6* STG-to-C glue. (gdb) break StgRun Breakpoint 1 at 0x1212c6298: file StgCRun.c, line 6. # run it: Breakpoint 1, 0x1212c6298 in StgRun () at StgCRun.c:6 6* STG-to-C glue. (gdb) step 0x1212c6728 in stg_init () at StgStartup.hc:6 (gdb) step # I ^C it after a little while: Program received signal SIGINT, Interrupt. 0x1212c62b0 in StgRun () at StgCRun.c:6 6* STG-to-C glue. So it stalls or loops (it sits at 98% of cpu) on entry to stg_init(). More info will have to wait until I try a debug build. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Fri, Sep 12, 2003 at 10:59:05AM +0100, Simon Marlow wrote:
>
> Looks like you need some mangler support now...
Unfortunately neither the mangler nor alpha are exactly strong points of
mine.
I'm also somewhat confused by how
die "Prologue junk?: $p\n" if $p =~ /^\s+[^\s\.]/;
[...]
# On Alphas, the prologue mangling is done a little later (below)
[...]
if ( $TargetPlatform =~ /^alpha-/ && $c =~ /^\t\.ent\s+(\S+)/ ) {
[prologue mangling]
is supposed to play together.
In other news, looks like porky.devel.redhat.com (linked to from the
archive pages) has ceased to exist and list messages aren't getting
through, although I can't see that host mentioned (under that name at
least) in message headers.
Thanks
Ian
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
igloo:
> With the wrapper everything was fine here on the host side.
>
> I then had to do the I_ -> int stg_exit thing as committed to CVS for
> IA64, and also change machine/{pal,fpu}.h to asm/{pal,fpu}.h in
> ghc/rts/Adjuster.c and ghc/rts/Signals.c. (I'd already applied the
> MBLOCK hack from x86-64). The compile then failed with
I got another (loopy) compile on alpha-dec-osf3 that went through
cleanly, with the following fixes:
On the x86-*-openbsd host:
*
==fptools== gmake all - --no-print-directory -r;
in /home/dons/unreg/ghc-6.0.1/libraries/base/cbits
[..]
gcc -O -Wall -DCOMPILING_STDLIB -I../../../ghc/includes
-I../../../ghc/rts -I../include-c longlong.c -o longlong.o
In file included from ../../../ghc/includes/Stg.h:189,
from ../../../ghc/includes/Rts.h:20,
from longlong.c:29:
../../../ghc/includes/TailCalls.h:86: invalid register name for `_procedure'
# Fixed by adding to libraries/mk/boilerplate.mk:
SRC_CC_OPTS+= -DUSE_MINIINTERPRETER
On the alpha target:
* gcc -O -DNO_REGS -DUSE_MINIINTERPRETER
-I/import/pill0/1/dons/ghc/alpha-osf3/ghc-6.0.1/ghc/includes
-I/import/pill0/1/dons/ghc/alpha-osf3/ghc-6.0.1/libraries/base/include
-I/import/pill0/1/dons/ghc/alpha-osf3/ghc-6.0.1/libraries/unix/include
-Wall -W -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Winline -Waggregate-return
-Wbad-function-cast -I../includes -I. -Iparallel -DCOMPILING_RTS
-fomit-frame-pointer-c BlockAlloc.c -o BlockAlloc.o
In file included from BlockAlloc.c:24:
MBlock.h:79: #error HEAP_ALLOCED not defined
# fix: Applied MBlock.h x86_64 fix/hack
* conflicting types for `stg_exit'
# fix: I_ -> int in ghc/rts/RtsUtils.h ghc/includes/PrimOps.h
* Can't locate file for: -lreadline
collect2: ld returned 1 exit status
# fix: comment out readline in mk/bootstrap.mk
And then everything went though, to the re-configure part of
hc-build, but the ghc-inplace seems to go into an infinite loop
on invocation. It won't produce output even with invalid command
line flags. It just sits and spins for a few minutes, and then I
have to kill it.
The only interesting thing is that it ignores the first ^C, and
requires a second ^C to die.
I'll try a debug build of some kind. Unless someone has some
better idea.
-- Don
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> but > > -- > -- > ===fptools== Recursively making `boot' in base haskell98 > network haskell-src unix ... > PWD = /scratch/users/eden/ghc-6.0.1/libraries > -- > -- > -- > -- > ==fptools== gmake boot -r; > in /scratch/users/eden/ghc-6.0.1/libraries/base > -- > -- > ../../ghc/utils/ghc-pkg/ghc-pkg-inplace --update-package > /usr/users/eden/scratch/ghc-6.0.1/ghc/driver/package.conf.inpl > ace: parse error in package config file > gmake[1]: *** [../../ghc/driver/stamp-pkg-conf-base] Error 1 > gmake: *** [boot] Error 1 Have you done 'make boot' in ghc/driver? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> With the wrapper everything was fine here on the host side.
>
> I then had to do the I_ -> int stg_exit thing as committed to CVS for
> IA64, and also change machine/{pal,fpu}.h to asm/{pal,fpu}.h in
> ghc/rts/Adjuster.c and ghc/rts/Signals.c. (I'd already applied the
> MBLOCK hack from x86-64). The compile then failed with
>
> gcc -O -Wall -DCOMPILING_STDLIB -I../../../ghc/includes
> -I../../../ghc/rts -I../include-c writeError.c -o writeError.o
> In file included from ../../../ghc/includes/Stg.h:189,
> from ../../../ghc/includes/Rts.h:20,
> from writeError.c:19:
> ../../../ghc/includes/TailCalls.h:86: warning: call-clobbered
> register used for global register variable
> writeError.c: In function `writeErrString__':
> writeError.c:47: error: unable to find a register to spill in
> class `R27_REG'
> writeError.c:47: error: this is the insn:
> (call_insn 31 30 34 1 0x279b970 (parallel [
> (call (mem:DI (reg/v/f:DI 9 $9 [69]) [0 S8 A64])
> (const_int 0 [0x0]))
> (use (reg:DI 29 $29))
> (clobber (reg:DI 26 $26))
> ]) 197 {*call_osf_1_er} (insn_list 30 (nil))
> (expr_list:REG_DEAD (reg:DI 27 $27)
> (expr_list:REG_DEAD (reg:DI 16 $16)
> (expr_list:REG_DEAD (reg/v/f:DI 9 $9 [69])
> (expr_list:REG_UNUSED (reg:DI 26 $26)
> (nil)
> (expr_list (use (reg:DI 16 $16))
> (nil)))
> writeError.c:47: confused by earlier errors, bailing out
> make[2]: *** [writeError.o] Error 1
> make[1]: *** [all] Error 1
> make: *** [all] Error 1
> make: Leaving directory `/home/igloo/ghc6-doc/ghc-6.0.1/libraries'
Hmm, Alpha should probably not be declaring that global register
variable in TailCalls.h when compiling ordinary C files. Try
surrounding the declaration with #ifdef IN_STG_CODE.
> Now I have
>
> ../../ghc/compiler/ghc-inplace -H16m -O -O2 -static-c
> Apply.hc -o Apply.o
> ghc-asm: unknown prologue mangling? alpha-unknown-linux
> Prologue junk?: .globl stg_ap_0_ret
> .ent stg_ap_0_ret
> stg_ap_0_ret:
> .eflag 48
> .frame $30,16,$26,0
> .mask 0x400,-16
> ldgp $29,0($27)
> $stg_ap_0_ret..ng:
> lda $30,-16($30)
> stq $26,0($30)
> .prologue 1
Looks like you need some mangler support now...
Cheers,
Simon
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Thu, Sep 11, 2003 at 07:53:02PM +1000, Donald Bruce Stewart wrote:
> simonmar:
> >
> > > 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.
> >
> > Is this when running gcc on the Alpha, or on the bootstrapping host?
>
> alpha-dec-osf3 bootstrapped quite cleanly today. Using the right
> config.h makes a big difference ;) It isn't working yet though.
>
> I had to comment out/hack various decls in the rts on the alpha,
> which let the compile go through. The GHC that got built seems to
> loop when invoked. Probably an MBlock thing, I haven't looked
> into it yet.
With the wrapper everything was fine here on the host side.
I then had to do the I_ -> int stg_exit thing as committed to CVS for
IA64, and also change machine/{pal,fpu}.h to asm/{pal,fpu}.h in
ghc/rts/Adjuster.c and ghc/rts/Signals.c. (I'd already applied the
MBLOCK hack from x86-64). The compile then failed with
gcc -O -Wall -DCOMPILING_STDLIB -I../../../ghc/includes -I../../../ghc/rts
-I../include-c writeError.c -o writeError.o
In file included from ../../../ghc/includes/Stg.h:189,
from ../../../ghc/includes/Rts.h:20,
from writeError.c:19:
../../../ghc/includes/TailCalls.h:86: warning: call-clobbered register used for global
register variable
writeError.c: In function `writeErrString__':
writeError.c:47: error: unable to find a register to spill in class `R27_REG'
writeError.c:47: error: this is the insn:
(call_insn 31 30 34 1 0x279b970 (parallel [
(call (mem:DI (reg/v/f:DI 9 $9 [69]) [0 S8 A64])
(const_int 0 [0x0]))
(use (reg:DI 29 $29))
(clobber (reg:DI 26 $26))
]) 197 {*call_osf_1_er} (insn_list 30 (nil))
(expr_list:REG_DEAD (reg:DI 27 $27)
(expr_list:REG_DEAD (reg:DI 16 $16)
(expr_list:REG_DEAD (reg/v/f:DI 9 $9 [69])
(expr_list:REG_UNUSED (reg:DI 26 $26)
(nil)
(expr_list (use (reg:DI 16 $16))
(nil)))
writeError.c:47: confused by earlier errors, bailing out
make[2]: *** [writeError.o] Error 1
make[1]: *** [all] Error 1
make: *** [all] Error 1
make: Leaving directory `/home/igloo/ghc6-doc/ghc-6.0.1/libraries'
(gcc is 3.3). Same thing with different optimisation levels but 2.95
compiled it fine. Is this the same as the problem you had on sparc,
Simon?
I gcc -E'd and then removed unused stuff to try to get something to send
off as a bug report, but then found the result compiled under 3.3 so
kept going.
This resulted in a working compiler, so I tried to build ghc using it
with gcc-2.95. I had to move the #include "TailCalls.h" up in
ghc/includes/Stg.h to get the
register void *_procedure __asm__("$27");
above all the function definitions.
Now I have
../../ghc/compiler/ghc-inplace -H16m -O -O2 -static-c Apply.hc -o Apply.o
ghc-asm: unknown prologue mangling? alpha-unknown-linux
Prologue junk?: .globl stg_ap_0_ret
.ent stg_ap_0_ret
stg_ap_0_ret:
.eflag 48
.frame $30,16,$26,0
.mask 0x400,-16
ldgp $29,0($27)
$stg_ap_0_ret..ng:
lda $30,-16($30)
stq $26,0($30)
.prologue 1
and I'm going to bed.
Ian
___
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> The bootstrapping host. That is expected, then. I've mentioned before that trying to build the HC files on the bootstrapping host might not work, because these files are meant to be built on the target. The same goes for the invocation of gcc itself: it is using flags designed for use on the target machine. > Oh, and while I think about it, on the building docs: > > Minor niggle - missing "cd T" on the first line > "$ ./configure --enable-hc-boot --enable-hc-boot-unregisterised" added, thanks. > When you say "change TARGETPLATFORM appropriately." I've been assuming > you mean the name of the foo_TARGET_ARCH etc variables too. Yes, I'll update the docs to say that too. > Presumably this is the same as passing configure > --target=what-remote-one-says ? configure doesn't cope with different --host/--target at the moment. There's no reason in principle why it shouldn't. Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
On Thu, Sep 11, 2003 at 09:52:07AM +0100, Simon Marlow wrote: > > > 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. > > Is this when running gcc on the Alpha, or on the bootstrapping host? The bootstrapping host. Oh, and while I think about it, on the building docs: Minor niggle - missing "cd T" on the first line "$ ./configure --enable-hc-boot --enable-hc-boot-unregisterised" When you say "change TARGETPLATFORM appropriately." I've been assuming you mean the name of the foo_TARGET_ARCH etc variables too. Presumably this is the same as passing configure --target=what-remote-one-says ? Thanks Ian ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 0x41e6177a, > > ip=0x40dd46c1 > > > > 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
simonmar: > > > 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. > > Is this when running gcc on the Alpha, or on the bootstrapping host? alpha-dec-osf3 bootstrapped quite cleanly today. Using the right config.h makes a big difference ;) It isn't working yet though. I had to comment out/hack various decls in the rts on the alpha, which let the compile go through. The GHC that got built seems to loop when invoked. Probably an MBlock thing, I haven't looked into it yet. Anyway, I assume Ian was talking about the bootstrapped GHC on the target rejecting -mieee when being used to compile a full GHC. I didn't get that far, but I had no problems with -mieee on the host, or with .hc file-booting gcc. -- Don ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> 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. Is this when running gcc on the Alpha, or on the bootstrapping host? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 0x41e6177a, ip=0x40dd46c1 > > 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 0x41e6177a, ip=0x40dd46c1 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: stg_ap_v_ret porting crash: solved?
> $ 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" Congrats :-) Would you like to add this port to the relevant section of the Building Guide? Cheers, Simon ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: stg_ap_v_ret porting crash: solved?
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 stepsbut 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 ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
