$ parrot -o mops.pbc mops.pasm
$ parrot -j mops.pbc
782.604453 M op/s
$ parrot -o mops.o mops.pbc
$ make exec EXEC=mops
exec_start.c
cc -o mops -L/usr/local/lib -g mops.o exec_start.o
blib/lib/libparrot.a -lnsl -ldl -lm -lposix -lcrypt -lutil
$ ./mops
Segmentation fault (core dumped)
$ gdb mops core
GNU gdb 5.3
...
Core was generated by `./mops'.
Program terminated with signal 11, Segmentation fault.
#0 0x40001990 in interpre ()
(gdb) bac
#0 0x40001990 in interpre ()
(gdb) r mops
Starting program: /opt/src/parrot-leo/mops mops
Warning:
Cannot insert breakpoint -2.
Error accessing memory address 0x4000ab10: Input/output error.
The same program may be running in another process.
(gdb) q
The debugger doesn't really like this file. Anyway, what assumptions
does EXEC have WRT the packfile, e.g. fixed order first const_table then
bytecode or such?
What info does EXEC need, to write out the object file?
EXEC should probably get a set of callback functions (s.
pf_register_standard_funcs) for each of the segment types.
leo
I could not reproduce the error here.
> The debugger doesn't really like this file. Anyway, what assumptions
> does EXEC have WRT the packfile, e.g. fixed order first const_table then
> bytecode or such?
No, it just stores the offset of the bytecode.
> What info does EXEC need, to write out the object file?
From the packfile, the offset of the bytecode and the size of constant table.
> EXEC should probably get a set of callback functions (s.
> pf_register_standard_funcs) for each of the segment types.
>
> leo
Daniel
Just checked in a patch that should solve it, but it's temporary since it's
overwriting something somewhere :), I'll track it down.
Daniel.
> Just checked in a patch that should solve it, but it's temporary since it's
> overwriting something somewhere :), I'll track it down.
Works for me.
> Daniel.
leo