lib/Parrot/Pmc2c.pm
lib/Parrot/Vtable.pm
classes/ref.pmc
classes/sharedref.pmc
config/gen/makefiles/root.in
Looking at the diffs, the only change I can see is to
the bxor MMD stuff Leo did. Not sure what that has to
do with the price of rice in China though.
Previously when it was not working, it would coredump.
It was working fine after fixing the intval/opcode
sizes to long and ICU.
Now the failure is:
parrot -j examples/benchmarks/primes2.pasm
exists_keyed() not implemented in class 'PerlInt'
Cheers
Joshua Gatcomb
a.k.a. Limbic~Region
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs
http://hotjobs.sweepstakes.yahoo.com/careermakeover
> 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.
> Cheers
> Joshua Gatcomb
Thanks for reporting,
leo
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?
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
Ok, I am an idiot. I didn't try the -j option. Still
not working as of 12:44PM EDT.
> 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.
> cvsuser 04/05/10 07:48:52
> Modified: build_tools jit2h.pl
> Log:
> mmd_vtables 10 - fix JIT_i386 - skip MMD_BXOR
>
> Revision Changes Path
> 1.62 +2 -1 parrot/build_tools/jit2h.pl
>
> Index: jit2h.pl
> ===================================================================
> RCS file: /cvs/public/parrot/build_tools/jit2h.pl,v
> retrieving revision 1.61
> retrieving revision 1.62
> diff -u -w -r1.61 -r1.62
> --- jit2h.pl 26 Apr 2004 17:03:08 -0000 1.61
> +++ jit2h.pl 10 May 2004 14:48:51 -0000 1.62
> @@ -1,6 +1,6 @@
> #! perl -w
> # Copyright: 2001-2003 The Perl Foundation. All Rights Reserved.
> -# $Id: jit2h.pl,v 1.61 2004/04/26 17:03:08 leo Exp $
> +# $Id: jit2h.pl,v 1.62 2004/05/10 14:48:51 leo Exp $
>
> =head1 NAME
>
> @@ -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++;
> }
leo
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'
> leo
I will just be patient and wait until tomorrow.
Thanks
Joshua Gatcomb
a.k.a. Limbic~Region
On Monday 10 May 2004 20:43, Joshua Gatcomb wrote:
> 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]
>
> I will just be patient and wait until tomorrow.
Try "cvs update -d -P -A"
> Thanks
> Joshua Gatcomb
> a.k.a. Limbic~Region
jens
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.
> 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
should make it running again.
leo
Previously I had only been verifying that -j was
working by trying a handful of the examples. 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
2 tests and 54 subtests skipped.
Failed 1/92 test scripts, 98.91% okay. 6/1463 subtests
failed, 99.59% okay.
make: *** [testj] Error 14
Not sure if this is expected or not.
You mean there's another way to operate computers? (After spending my
teenage years caffeinating and hacking, no caffeine supply is "ample"
anymore.)
--
Brent "Dax" Royal-Gordon <br...@brentdax.com>
Perl and Parrot hacker
Oceania has always been at war with Eastasia.
> 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:
$ perldoc -F docs/jit.pod
/debugging
I hope that works for Cygwin too.
> Not sure if this is expected or not.
No, runs fine here on i386/linux.
> Joshua Gatcomb
leo
$ parrot arithmetics_26.pasm
ok 1
ok 2
ok 3
ok 4
$ parrot -j arithmetics_26.pasm
ok 1
ok 2
ok 3
ok 4
Illegal instruction (core dumped)
$ for i in 9 10 11 12 17 18
> do
> echo "parrot trans_$i.pasm"
> parrot trans_$i.pasm
> echo "parrot -j trans_$i.pasm"
> parrot -j trans_$i.pasm
> done
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 ?? ()
> leo
Cheers
Joshua Gatcomb
a.k.a. Limbic~Region
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861
> 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.
leo
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.
REGULAR TRACE
128 eq I2, I7, 6 - I2=5, I7=5,
134 print "ok 4\n"
ok 4
PC=136; OP=<err>
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?
> 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.
> Joshua Gatcomb
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.
Cheers
Joshua Gatcomb
__________________________________
Do you Yahoo!?
Yahoo! Domains – Claim yours for only $14.70/year
http://smallbusiness.promotions.yahoo.com/offer