> > parrot -j examples/benchmarks/primes2.pasm > > exists_keyed() not implemented in class 'PerlInt'
> Ah. yep. Due to eliminating two vtable functions, > other ones after that > moved down in table. JIT needs a small adjustment.
> Fixed.
Before I posted, I updated again with the latest checkout and saw that I am still having the problem. It has been about an hour since you said it was fixed and I am not seeing it. Is there some CVS trickery I should be doing?
>--- Leopold Toetsch <l...@toetsch.at> wrote: >> Joshua Gatcomb <limbic_region_2...@yahoo.com> wrote:
>> > parrot -j examples/benchmarks/primes2.pasm >> > exists_keyed() not implemented in class 'PerlInt'
>> Ah. yep. Due to eliminating two vtable functions, >> other ones after that >> moved down in table. JIT needs a small adjustment.
>> Fixed.
>Working great now. Not sure why it took so long >before I could see the update in CVS. Thanks and >please disregard earlier message.
Ah, don't worry--I'm going to break it soon with the rest of the vtable shift. :) -- Dan
--------------------------------------"it's like this"------------------- Dan Sugalski even samurai d...@sidhe.org have teddy bears and even teddy bears get drunk
Joshua Gatcomb <limbic_region_2...@yahoo.com> wrote: > Before I posted, I updated again with the latest > checkout and saw that I am still having the problem. > It has been about an hour since you said it was fixed > and I am not seeing it. Is there some CVS trickery I > should be doing?
Dunno. You can follow CVS updates at the cvs mailing list or at the news group perl.cvs.parrot.
It was this 1-liner check in below. "make testj" runs fine now.
> @@ -208,6 +208,7 @@ > my $i = 0; > $vjit++; > for my $entry (@{$vtable}) { > + next if $entry->[4] =~ /MMD_BXOR/; # TODO all > return $i if ($entry->[1] eq $meth); > $i++; > }
> Dunno. You can follow CVS updates at the cvs mailing > list or at the news group perl.cvs.parrot.
Thanks - next time I see "fixed" and doing a cvs update -dP doesn't pick up the change I will know where to look.
> It was this 1-liner check in below. "make testj" > runs fine now.
Oddly enough "make testj" does not run fine for me. I reverted back to the 7:05AM checkout to test. Even though parrot -j <file> works, numerous tests fail. "make test" has all tests passing.
> Modified: build_tools jit2h.pl
This is really odd. I did "rm build_tools/jit2h.pl" and then cvs update -dP and got back the same old file. I made the 1 line change myself by hand. Now I am getting repeat() not implemented in class 'PerlInt'
> Thanks - next time I see "fixed" and doing a cvs > update -dP doesn't pick up the change I will know > where to look.
> > It was this 1-liner check in below. "make testj" > > runs fine now.
> Oddly enough "make testj" does not run fine for me. I > reverted back to the 7:05AM checkout to test. Even > though parrot -j <file> works, numerous tests fail. > "make test" has all tests passing.
> > Modified: build_tools jit2h.pl
> This is really odd. I did "rm build_tools/jit2h.pl" > and then cvs update -dP and got back the same old > file. [snip]
> Dunno. You can follow CVS updates at the cvs mailing > list or at the news group perl.cvs.parrot.
Just a hunch but I bet it is a timezone problem. I just did a cvs update -dP -D"2004-05-10 23:59", which is in the future for me. It picked up a handful of changes. Then I verified that -j is now working.
I will shut up now. One should not be allowed to operate computers when over tired without ample supply of caffeine.
Joshua Gatcomb <limbic_region_2...@yahoo.com> wrote: > --- Leopold Toetsch <l...@toetsch.at> wrote: >> Dunno. You can follow CVS updates at the cvs mailing >> list or at the news group perl.cvs.parrot. > Thanks - next time I see "fixed" and doing a cvs > update -dP doesn't pick up the change I will know > where to look.
It's not too bad to read that anyway (not much traffic, just me :). You'll find some notes there that read:
mmd_vtables 8 ... Please re-Configure && make ... mmd_vtables 9 ... Please make clean; perl Configure.pl ...
I know that theoretically the Makefile should take care of all these dependencies (I just added one missing today) But by far not all are in.
Mainly any file that is generated by $OUR_TOOL depends on changes to $OUR_TOOL. A lot of such rules are still missing. We need also a clean way to reconfigure with the _very same options_ as Configure.pl was run and include that dependency in the Makefile--grep for STICKY_FILES.
Then just "make reconfig" or such should generate all needed changes to these STICKY_FILES. And yes--that may generate a new Makefile to run, which we are currently running. A "please restart make" message for these rare cases could be ok, though.
Any contributions WRT that (not only of course) are very welcome.
Back to the OP.
make realclean; perl Configure.pl --your-options && make all fulltest
Joshua Gatcomb <limbic_region_2...@yahoo.com> wrote: > ... This is > the result of running 'make testj'. > Failed Test Stat Wstat Total Fail Failed List of > Failed > ------------------------------------------------------------------ > t/op/trans.t 6 1536 19 6 31.58% 9-12 17-18
Strange. Can you run the failing tests standalone and compare results? It would also be great if you can debug JIT directly by following the hints in:
parrot trans_9.pasm ok 1 ok 2 parrot -j trans_9.pasm ok 1 not ok 2 parrot trans_10.pasm ok 1 ok 2 parrot -j trans_10.pasm not ok 1 not ok 2 parrot trans_11.pasm ok 1 ok 2 parrot -j trans_11.pasm not ok 1 not ok 2 parrot trans_12.pasm ok 1 ok 2 parrot -j trans_12.pasm ok 1 not ok 2 parrot trans_17.pasm ok 1 ok 2 parrot -j trans_17.pasm ok 1 not ok 2 parrot trans_18.pasm ok 1 ok 2 ok 3 ok 4 ok 5 ok 6 ok 7 ok 8 ok 9 ok 10 ok 11 ok 12 ok 13 ok 14 ok 15 ok 16 parrot -j trans_18.pasm not ok 1 not ok 2 not ok 3 not ok 4 not ok 5 not ok 6 ok 7 ok 8 ok 9 ok 10 not ok 11 not ok 12 ok 13 not ok 14 not ok 15 ok 16
> It would also be great if you can debug JIT directly > by following the > hints in:
> $ perldoc -F docs/jit.pod > /debugging
> I hope that works for Cygwin too.
I couldn't figure out how to copy/paste from a Cygwin X window to a Window window, so I did it by hand. Is this what you mean?
$ gdb parrot GNU gdb 2003-09-20-cvs (cygwin-special) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) b runops_jit Breakpoint 1 at 0x466bf6: file src/interpreter.c, line 548. (gdb) r -d -j arithmetics_26.pasm Starting program: /perl/parrot/parrot.exe -d -j arithmetics_26.pasm
Program received signal SIGSEGV, Segmentation fault. 0x77e75a3d in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll (gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x77e75a3f in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll (gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x77e75a3d in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll (gdb) continue Continuing. *** Parrot VM: Setting stack top. *** *** Parrot VM: JIT core *** *** Parrot VM: Setting up ARGV array in P5. Current argc: 1 *** 0: arithmetics_26.pasm
Breakpoint 1, runops_jit (interpreter=0x100d1d80, pc=0x1029d938) at src/interpreter.c:548 548 jit_f jit_code = (jit_f) D2FPTR(init_jit(interpreter, pc)); (gdb) n 549 (jit_code) (interpreter, pc); (gdb) add-symbol-file arithmetics_26.o 0 add symbol table from file "arithmetics_26.o" at .text_addr = 0x0 (y or n) y Reading symbols from arithmetics_26.o...done. (gdb) s jit_func () at arithmetics_26.pasm:1 1 set I0, 130 (gdb) n 2 set I1, -35 (gdb) n 3 gcd I7, I0, I1 (gdb) n 6 gcd I2, I3, I4, I0, I1 (gdb) n 7 mul I5, I3, I0 (gdb) n 8 mul I6, I4, I1 (gdb) n 9 add I5, I5, I6 (gdb) n 10 ne I2, I5, NOK1 (gdb) n 11 eq I2, I7, OK1 (gdb) n 14 OK1: print "ok 1\n" (gdb) n ok 1 17 neg I0 (gdb) n 18 gcd I2, I3, I4, I0, I1 (gdb) n 19 mul I5, I3, I0 (gdb) n 20 mul I6, I4, I1 (gdb) n 21 add I5, I5, I6 (gdb) n 22 ne I2, I5, NOK2 (gdb) n 23 eq I2, I7, OK2 (gdb) n 26 OK2: print "ok 2\n" (gdb) n ok 2 29 neg I1 (gdb) n 30 gcd I2, I3, I4, I0, I1 (gdb) n 31 mul I5, I3, I0 (gdb) n 32 mul I6, I4, I1 (gdb) n 33 add I5, I5, I6 (gdb) n 34 ne I2, I5, NOK3 (gdb) n 35 eq I2, I7, OK3 (gdb) n 38 OK3: print "ok 3\n" (gdb) n ok 3 41 neg I0 (gdb) n 42 gcd I2, I3, I4, I0, I1 (gdb) n 43 mul I5, I3, I0 (gdb) n 44 mul I6, I4, I1 (gdb) n 45 add I5, I5, I6 (gdb) n 46 ne I2, I5, NOK4 (gdb) n 47 eq I2, I7, OK4 (gdb) n 50 OK4: print "ok 4\n" (gdb) n ok 4
Program received signal SIGSEGV, Segmentation fault. 0x102b2ec5 in ?? ()
Joshua Gatcomb <limbic_region_2...@yahoo.com> wrote: > parrot trans_9.pasm > ok 1 > ok 2 > parrot -j trans_9.pasm > ok 1 > not ok 2
[ ... ]
> (gdb) add-symbol-file arithmetics_26.o 0 > add symbol table from file "arithmetics_26.o" at > .text_addr = 0x0 > (y or n) y > Reading symbols from arithmetics_26.o...done. > (gdb) s > jit_func () at arithmetics_26.pasm:1 > 1 set I0, 130
Good. So you can step through the JIT code.
Now comes the easy thing: find out, why the results differ:
- run the test through the plain core and trace it: $ parrot -t t/op/trans_9.pasm ... 50 cosh N2, I1 - N2=1.543081, I1=1
- run it through JIT debugging: ... # after the 2nd cosh # (gdb) p N2 $1 = 1.5430806348152437 (gdb) p I1 $2 = 1
You can turn on the register window of ddd too (or type "info float" and "info registers" in gdb). Something must happen here that gives differing results and segfaults.
Yes and no. On Monday, arithmetics_26 was not coredumping parrot under JIT that I can remember. It is now, but I am able to debug/trace with JIT. I am not sure what to do since comparing the trace to the JIT trace shows both print ok for all 4 tests, the JIT version just coredumps after.
JIT TRACE 47 eq I2, I7, OK4 (gdb) n 50 OK4: print "ok 4\n" (gdb) n ok 4 Program received signal SIGSEGV, Segmentation fault. 0x102a3901 in ?? ()
trans_9 does not coredump, it just says the test is not ok. I can't however debug/trace it with JIT. This means I can't see where things go wrong:
$ parrot -o trans_9.pbc -d trans_9.pasm $ gdb parrot GNU gdb 2003-09-20-cvs (cygwin-special) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) b runops_jit Breakpoint 1 at 0x466bf6: file src/interpreter.c, line 548. (gdb) r -d -j trans_9.pbc Starting program: /perl/parrot/parrot.exe -d -j trans_9.pbc
Program received signal SIGSEGV, Segmentation fault. 0x77e75a3d in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll (gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x77e75a3f in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll (gdb) continue Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x77e75a3d in KERNEL32!IsBadWritePtr () from /cygdrive/c/WINDOWS/system32/kernel32.dll (gdb) continue Continuing. *** Parrot VM: Setting stack top. *** *** Parrot VM: JIT core *** *** Parrot VM: Setting up ARGV array in P5. Current argc: 1 *** 0: trans_9.pbc
Breakpoint 1, runops_jit (interpreter=0x100d1d80, pc=0x3f00e0) at src/interpreter.c:548 548 jit_f jit_code = (jit_f) D2FPTR(init_jit(interpreter, pc)); (gdb) n
Program received signal SIGSEGV, Segmentation fault. 0x00522808 in Parrot_jit_debug_stabs (interpreter=0x100d1d80) at src/jit_debug.c:348 348 fprintf(stabs, ".stabn " N_SLINE ",0,%d,%d /* %s */\n", line, (gdb)
WRT arithmetics_26 that coredumps, but I can debug/trace with JIT - what should I look for?
WRT trans_9-12,17,18 that does not coredump and I can't debug/trace with JIT - what should I do next?
Joshua Gatcomb <limbic_region_2...@yahoo.com> wrote: > Program received signal SIGSEGV, Segmentation fault. > 0x00522808 in Parrot_jit_debug_stabs > (interpreter=0x100d1d80) at src/jit_debug.c:348 > 348 fprintf(stabs, ".stabn " N_SLINE > ",0,%d,%d /* %s */\n", line,
I saw that one too with some files. Some bug lurking around related to line numbers. You could copy the PASM source file and remove empty lines and comments.
> I saw that one too with some files. Some bug lurking > around related to line numbers. You could copy the PASM > source file and remove empty lines and comments.
> leo
I didn't have a chance to play with parrot at all this week. Tonight, I decided to try and get it running on Win ME just to see.
After building the recent alpha release of ICU 3.0, I was able to build parrot with 0 problems.
I went straight for trans_9 to see if it core dumped:
parrot -d -j trans_9.pasm
No core dump, which I thought was a good sign. It meant I should be able to debug it and not have to worry about the comments/empty lines/etc. Unfortunately, I get the following:
(gdb) File parrot.exe Reading symbols from parrot.exe...(no debugging symbols found)...done.
I will report on Monday when I am back at work and in my usual environment WRT this being a problem with Win ME or something that has changed within the last week.
