YHC hackers, I've managed to run hello world with YHC on AMD64. This required changing the definition of UShort type from HALF_TYPE which is 32-bit int to short. The problem lied in mutator.c where jTable variable was meant to contain 2-byte integers but contained 4-byte integers on AMD64 and jumps were calculated wrong. The patch I've attached is only for reference. I don't know what is the correct type for UShort (or maybe jTable shouldn't be UShort * ?). I wanted to run some tests and was pointed to src/tester by Neil. However, all the test failed because of some Makefile problems. Output attached. Do you have any nontrivial code that runs on YHC/i386? I would like to test it on my machine. Thanks, Michal --------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
Hi Mike, Michał Pałka wrote:
I've managed to run hello world with YHC on AMD64. This required changing the definition of UShort type from HALF_TYPE which is 32-bit int to short. The problem lied in mutator.c where jTable variable was meant to contain 2-byte integers but contained 4-byte integers on AMD64 and jumps were calculated wrong.
Thanks indeed, I don't imagine that bug would have been easy to find.
The patch I've attached is only for reference. I don't know what is the correct type for UShort (or maybe jTable shouldn't be UShort * ?).
Gah, that was a foolish oversight of mine! No the jtable shouldn't use a UShort it should use a UInt16, it's always 2 bytes irrespective of platform word size. I'm tempted to kill UShort altogether and rename it UHalf, I've made several mistakes using the wrong one. I'm amazed that HelloWorld still worked with UShort as a 16bit int on a 64bit platform. I would have expected that to break it.
I wanted to run some tests and was pointed to src/tester by Neil. However, all the test failed because of some Makefile problems. Output attached.
Well they don't quite all have make errors, but that is rather more than expected.
Do you have any nontrivial code that runs on YHC/i386? I would like to test it on my machine.
I don't know much about Neil's tester, so I'll let him answer that one ... Cheers Tom
Well they don't quite all have make errors, but that is rather more than expected. They probably *do* all have make errors. If a program is invalid and the make fails, thats considered as success - about 14 sounds like a reasonable number.
I don't know much about Neil's tester, so I'll let him answer that one ... You are probably invoking it with a combination of wrong directories, from the wrong directory, or with the wrong voodoo environment variables - I remember it was kind of hard to get the windows one going, and all that logic is now encoded in the windows makefile. I'll talk to Tom tomorrow and see if we can hack up a makefile that will do the testing on Unix. I would hope that given you can do hello world, you'll get a reasonable amount of success with the tests.
Thanks Neil
Hi, I've (hopefully) fixed the UShort/UInt16 issue on AMD64 (though it's kind of hard for me to test). Also a couple of patches have been added to the repository that mean make tests should now run a load of unit tests. You'll need to re-run configure after pulling the patches though, as it changes Makefile.in. Hope that helps :-) Tom Neil Mitchell wrote:
I'll talk to Tom tomorrow and see if we can hack up a makefile that will do the testing on Unix. I would hope that given you can do hello world, you'll get a reasonable amount of success with the tests.
Hello, The runtime was segfaulting for me, but, together with Neil, we found a fix for that (attached). I was also able to run the tests and most of them succeeded(!): Passed: 50 Failed: 1 Total : 51 The one that failed was Queens which failed with this error: yhi: jonkers.c:58: jonk_thread: Assertion `*p >= (Node*)G_hpStart && *p <= (Node*)G_hp' failed. Aborted I suppose that it's the only test that make the gc to run. I'll try to look at this problem tomorrow. Michal On Fri, 2006-03-10 at 12:07 +0000, Thomas Shackell wrote:
Hi,
I've (hopefully) fixed the UShort/UInt16 issue on AMD64 (though it's kind of hard for me to test).
Also a couple of patches have been added to the repository that mean
make tests
should now run a load of unit tests.
You'll need to re-run configure after pulling the patches though, as it changes Makefile.in.
Hope that helps :-)
Tom
Neil Mitchell wrote:
I'll talk to Tom tomorrow and see if we can hack up a makefile that will do the testing on Unix. I would hope that given you can do hello world, you'll get a reasonable amount of success with the tests.
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
Hackers, I've managed to find more details concerning GC failure on AMD64. The heap node that causes GC to crash is allocated on modules loading: #0 cinfo_alloc (size=2, name=0x58a3e0 ":", number=1, flags=0, obj=0x58a360) at info.c:24 #1 0x0000000000403b0f in mod_loadCon (mod=0x52ccf0, name=0x58a3e0 ":", obj=0x58a360) at module.c:463 #2 0x0000000000403ccd in mod_loadObject (mod=0x52ccf0, offs=36277, obj=0x58a360) at module.c:516 #3 0x0000000000402a13 in mod_resolve (module=0x58a380 "Prelude", item=0x58a3a0 ":") at module.c:209 #4 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a218) at module.c:322 #5 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a1e0 "valid", obj=0x58a160) at module.c:439 #6 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1475, obj=0x58a160) at module.c:514 #7 0x0000000000402a13 in mod_resolve (module=0x58a180 "Main", item=0x58a1a0 "valid") at module.c:209 #8 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a0f0) at module.c:322 #9 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a0c0 "queens", obj=0x58a040) at module.c:439 #10 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1580, obj=0x58a040) at module.c:514 #11 0x0000000000402a13 in mod_resolve (module=0x58a060 "Main", item=0x58a080 "queens") at module.c:209 #12 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x589fa8) at module.c:322 #13 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x589f80 "main", obj=0x589f40) at module.c:439 #14 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1606, obj=0x589f40) at module.c:514 #15 0x0000000000402a13 in mod_resolve (module=0x7fffffea0b88 "Main", item=0x41f3f1 "main") at module.c:209 #16 0x00000000004046ee in initGlobals (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:120 #17 0x0000000000404880 in init (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:145 #18 0x00000000004048de in main (argc=4, argv=0x7fffffea0348) at main.c:171 The node represents the (:) constructor which takes 2 arguments (size = 2), but the space allocated is only 1 word (no args[]). Why? Next node which occupies the next word is treated as pointer to args by the GC which leads to crash. Thanks, Michal --------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
Clarification On Sat, 2006-03-11 at 22:58 +0100, Michał Pałka wrote:
Hackers,
I've managed to find more details concerning GC failure on AMD64. The heap node that causes GC to crash is allocated on modules loading: #0 cinfo_alloc (size=2, name=0x58a3e0 ":", number=1, flags=0, obj=0x58a360) at info.c:24 #1 0x0000000000403b0f in mod_loadCon (mod=0x52ccf0, name=0x58a3e0 ":", obj=0x58a360) at module.c:463 #2 0x0000000000403ccd in mod_loadObject (mod=0x52ccf0, offs=36277, obj=0x58a360) at module.c:516 #3 0x0000000000402a13 in mod_resolve (module=0x58a380 "Prelude", item=0x58a3a0 ":") at module.c:209 #4 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a218) at module.c:322 #5 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a1e0 "valid", obj=0x58a160) at module.c:439 #6 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1475, obj=0x58a160) at module.c:514 #7 0x0000000000402a13 in mod_resolve (module=0x58a180 "Main", item=0x58a1a0 "valid") at module.c:209 #8 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a0f0) at module.c:322 #9 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a0c0 "queens", obj=0x58a040) at module.c:439 #10 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1580, obj=0x58a040) at module.c:514 #11 0x0000000000402a13 in mod_resolve (module=0x58a060 "Main", item=0x58a080 "queens") at module.c:209 #12 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x589fa8) at module.c:322 #13 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x589f80 "main", obj=0x589f40) at module.c:439 #14 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1606, obj=0x589f40) at module.c:514 #15 0x0000000000402a13 in mod_resolve (module=0x7fffffea0b88 "Main", item=0x41f3f1 "main") at module.c:209 #16 0x00000000004046ee in initGlobals (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:120 #17 0x0000000000404880 in init (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:145 #18 0x00000000004048de in main (argc=4, argv=0x7fffffea0348) at main.c:171
The node represents the (:) constructor which takes 2 arguments (size = 2), but the space allocated is only 1 word (no args[]). Why? Next node which occupies the next word is treated as pointer to args by the GC which leads to crash. Of course it's not treated as pointer to args, but rather as the first argument, which is also wrong.
Thanks, Michal
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
_______________________________________________ Yhc mailing list Yhc@haskell.org http://haskell.org/mailman/listinfo/yhc
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
Hi Michal, Yes I found exactly the same bug yesterday evening when I was rewriting the sanity checker (it now scans the heap linearly). The problem is simple, cinfo_alloc contained: if (obj){ zcon = (Node*)heap_alloc(wordsof(Node)); MAKE_NODE(zcon, cinfo, N_NORMAL); obj->node = zcon; obj->info = (Info*)cinfo; } which allocates a zero arity constructor node for the constructor (I just copy pased the code from finfo_alloc to allocate a CAF node). However, I forgot that not all constructors are zero arity and so not all need a zero arity node. So the code should read: if (obj){ if (cinfo->size == 0){ zcon = (Node*)heap_alloc(wordsof(Node)); MAKE_NODE(zcon, cinfo, N_NORMAL); obj->node = zcon; } obj->info = (Info*)cinfo; } I'll submit a patch shortly :-) Thanks very much for your efforts, it really has made my life easier :-) Tom Michał Pałka wrote:
Clarification
On Sat, 2006-03-11 at 22:58 +0100, Michał Pałka wrote:
Hackers,
I've managed to find more details concerning GC failure on AMD64. The heap node that causes GC to crash is allocated on modules loading: #0 cinfo_alloc (size=2, name=0x58a3e0 ":", number=1, flags=0, obj=0x58a360) at info.c:24 #1 0x0000000000403b0f in mod_loadCon (mod=0x52ccf0, name=0x58a3e0 ":", obj=0x58a360) at module.c:463 #2 0x0000000000403ccd in mod_loadObject (mod=0x52ccf0, offs=36277, obj=0x58a360) at module.c:516 #3 0x0000000000402a13 in mod_resolve (module=0x58a380 "Prelude", item=0x58a3a0 ":") at module.c:209 #4 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a218) at module.c:322 #5 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a1e0 "valid", obj=0x58a160) at module.c:439 #6 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1475, obj=0x58a160) at module.c:514 #7 0x0000000000402a13 in mod_resolve (module=0x58a180 "Main", item=0x58a1a0 "valid") at module.c:209 #8 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x58a0f0) at module.c:322 #9 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x58a0c0 "queens", obj=0x58a040) at module.c:439 #10 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1580, obj=0x58a040) at module.c:514 #11 0x0000000000402a13 in mod_resolve (module=0x58a060 "Main", item=0x58a080 "queens") at module.c:209 #12 0x0000000000402f0d in mod_loadConstTable (mod=0x588ea0, finfo=0x589fa8) at module.c:322 #13 0x0000000000403a4b in mod_loadFun (mod=0x588ea0, name=0x589f80 "main", obj=0x589f40) at module.c:439 #14 0x0000000000403cb4 in mod_loadObject (mod=0x588ea0, offs=1606, obj=0x589f40) at module.c:514 #15 0x0000000000402a13 in mod_resolve (module=0x7fffffea0b88 "Main", item=0x41f3f1 "main") at module.c:209 #16 0x00000000004046ee in initGlobals (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:120 #17 0x0000000000404880 in init (mainMod=0x7fffffea0b88 "Main", mainFunc=0x7fffffea0248, _toplevel=0x7fffffea0250, _driver=0x7fffffea0240) at main.c:145 #18 0x00000000004048de in main (argc=4, argv=0x7fffffea0348) at main.c:171
The node represents the (:) constructor which takes 2 arguments (size = 2), but the space allocated is only 1 word (no args[]). Why? Next node which occupies the next word is treated as pointer to args by the GC which leads to crash.
Of course it's not treated as pointer to args, but rather as the first argument, which is also wrong.
Thanks, Michal
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
_______________________________________________ Yhc mailing list Yhc@haskell.org http://haskell.org/mailman/listinfo/yhc
--------------------------------------------------------------------- Toshiba i FIFA World Cup Wygraj bilety i notebooki z Intel Centrino Duo Mobile Technology http://link.interia.pl/f1912
Hi, The patch I've pushed should hopefully fix this and also strengthen the sanity checking somewhat :-) Tom Tom Shackell wrote:
Hi Michal,
Yes I found exactly the same bug yesterday evening when I was rewriting the sanity checker (it now scans the heap linearly). The problem is simple, cinfo_alloc contained:
if (obj){ zcon = (Node*)heap_alloc(wordsof(Node)); MAKE_NODE(zcon, cinfo, N_NORMAL); obj->node = zcon; obj->info = (Info*)cinfo; }
which allocates a zero arity constructor node for the constructor (I just copy pased the code from finfo_alloc to allocate a CAF node). However, I forgot that not all constructors are zero arity and so not all need a zero arity node. So the code should read:
if (obj){ if (cinfo->size == 0){ zcon = (Node*)heap_alloc(wordsof(Node)); MAKE_NODE(zcon, cinfo, N_NORMAL); obj->node = zcon; } obj->info = (Info*)cinfo; }
I'll submit a patch shortly :-)
Thanks very much for your efforts, it really has made my life easier :-)
Tom
Fresh problem: newP = mkt_firstMarked(p); at line 163 in jonkers.c gives address p + 8 which is occupied by an argument to node under p. This causes newP to contain garbage when interpreted as Node*. The node under p is of this kind: {info = {tag = 2}, size = 1, name = 0x42a1fe "Int", number = 0, flags = 1}. Hope this helps, Michal On Sun, 2006-03-12 at 12:26 +0000, Tom Shackell wrote:
Hi,
The patch I've pushed should hopefully fix this and also strengthen the sanity checking somewhat :-)
Tom
------------------------------------------------------------------- Wzial udzial w zawodach balonowych i... niezle wypadl! KIM JEST STEFAN?!? | http://www.stefan.pl/
participants (4)
-
Michał Pałka -
Neil Mitchell -
Thomas Shackell -
Tom Shackell