The MIPSPro compiler is not happy with Parrot (it used to be though).
Everything is fine with gcc on the same system, which implies that some
nastiness has slipped in at some point.
I think it may have something to do with these warnings:
[gcc] ld32: WARNING 105: Common symbol "runops_cores" defined in
interpreter.o is resolved with a data definition in runops_cores.o
with a smaller alignment.
[MIPS] ld32: WARNING 15 : Multiply defined:(runops_cores) in interpreter.o and
runops_cores.o (2nd definition ignored).
Playing with gdb gets me to:
[gcc]
97 core = runops_cores[which];
(gdb) print core
$1 = (opcode_t *(*)(struct Parrot_Interp *, opcode_t *)) 0x158
(gdb) print runops_cores
$2 = {0x10017ea0 <runops_t0p0b0_core>, 0x10017f48 <runops_t0p0b1_core>,
0x10018058 <runops_t0p1b0_core>, 0x10018160 <runops_t0p1b1_core>,
0x100182d0 <runops_t1p0b0_core>, 0x100183b8 <runops_t1p0b1_core>,
0x10018500 <runops_t1p1b0_core>, 0x10018648 <runops_t1p1b1_core>}
(gdb) n
99 if ((interpreter->flags & PARROT_PROFILE_FLAG) != 0) {
(gdb) n
111 runops_generic(core, interpreter, pc);
(gdb) n
fact of 0 is: 1
....
[MIPS]
97 core = runops_cores[which];
(gdb) print core
$3 = (opcode_t *(*)()) 0
(gdb) n
99 if ((interpreter->flags & PARROT_PROFILE_FLAG) != 0) {
(gdb) print core
$4 = (opcode_t *(*)()) 0
(gdb) print runops_cores
$5 = {0, 0, 0, 0, 0, 0, 0, 0}
(gdb) print which
$6 = 0
(gdb) print runops_cores
$7 = {0, 0, 0, 0, 0, 0, 0, 0}
(gdb) n
111 runops_generic(core, interpreter, pc);
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x0 in ?? ()
I'm getting tired now, so someone else can inherit this headache.
Alex Gough
--
Tomatoes make you happy. Have you ever met a miserable
Italian? They are irritating but never miserable.
