xcore / tool_axe

An XCore Emulator
Other
15 stars 8 forks source link

Segmentation fault #2

Closed jameshanlon closed 13 years ago

jameshanlon commented 13 years ago

hanlon@buzz:~/repos/tool_axe$ cat test.xc

include

void foo() { while(1) {}; }

int main() { par { on stdcore[0]: foo(); on stdcore[1]: foo(); on stdcore[2]: foo(); on stdcore[3]: foo(); } return 0; } hanlon@buzz:~/repos/tool_axe$ xcc test.xc -target=XC-1 hanlon@buzz:~/repos/tool_axe$ ./build/axe a.xe Segmentation fault

rlsosborne commented 13 years ago

In a debug build this hits an assertion when the program does a setd on a channel with 0xc30c. This is the address of the sswitch, and reads and writes of the sswitch aren't supported yet. Aside from adding support for sswitch / pswitch the code also needs updating to check whether the destination is valid.

rlsosborne commented 13 years ago

I've implemented just enough SSwitch support to get this working. Fixed in 248d0c15b9b5d9d19dd96bbb2e1fb9a93a409c63

jameshanlon commented 13 years ago

The SSwitch functionality works with my own scratch register read/write routines, presumably though the following code should also work:

include

void main() { unsigned v; write_sswitch_reg(0, 3, 0xDEADBEEF); read_sswitch_reg(0, 3, v); }

Compiling:

xcc -target=XC-1 test.xc

Produces the trace:

[c0t0] write_sswitch_reg(0x101f4): shr r3, r0(0x0), 16 # r3=0x0 [c0t0] write_sswitch_reg+2(0x101f6): bt r3(0x0), 32 [c0t0] write_sswitch_reg+4(0x101f8): shr r3, r1(0x3), 16 # r3=0x0 [c0t0] write_sswitch_reg+6(0x101fa): bt r3(0x0), 30 [c0t0] write_sswitch_reg+8(0x101fc): getr r3, 2 # r3=0x2 [c0t0] write_sswitch_reg+10(0x101fe): ldc r11, 49932 # r11=0xc30c [c0t0] write_sswitch_reg+14(0x10202): bu 7 [c0t0] write_switch_reg(0x10212): shl r0, r0(0x0), 16 # r0=0x0 [c0t0] write_switch_reg+2(0x10214): or r0, r0(0x0), r11(0xc30c) # r0=0xc30c [c0t0] write_switch_reg+4(0x10216): setd res[r3(0x2)], r0(0xc30c) [c0t0] write_switch_reg+6(0x10218): ldc r11, 192 # r11=0xc0 [c0t0] write_switch_reg+10(0x1021c): outct res[r3(0x2)], r11(0xc0) [c0t0] write_switch_reg+12(0x1021e): shr r0, r3(0x2), 8 # r0=0x0 [c0t0] write_switch_reg+14(0x10220): shl r0, r0(0x0), 8 # r0=0x0 [c0t0] write_switch_reg+16(0x10222): shr r11, r1(0x3), 8 # r11=0x0 [c0t0] write_switch_reg+18(0x10224): or r0, r0(0x0), r11(0x0) # r0=0x0 [c0t0] write_switch_reg+20(0x10226): out r0(0x0), res[r3(0x2)] [c0t0] write_switch_reg+22(0x10228): outt res[r3(0x2)], r1(0x3) [c0t0] write_switch_reg+24(0x1022a): out r2(0xdeadbeef), res[r3(0x2)] [c0t0] write_switch_reg+26(0x1022c): outct res[r3(0x2)], 1 [n0] SSwitch write: register 0x3, value 0xdeadbeef, reply address 0x2 [n0] SSwitch reply: ACK, destintion 0x2 [c0t0] write_switch_reg+28(0x1022e): inct res[r0(0x0)], r3 [c0t0] ILLEGAL_RESOURCE exception

Although this looks like it might be a problem with write_sswitch_reg itself.

rlsosborne commented 13 years ago

This is a bug in the decoding of the inct instruction (operands are swapped). This should be fixed in d3f0d3be4664457c1be13bb5995f6574ee58bc1e