search

minscay / mupen64plus

Automatically exported from code.google.com/p/mupen64plus
0 stars 0 forks source link

Armorines - Project SWARM doesnt boot up in dynacore #279

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Describe your system:
 - Linux distribution: Debian sid
 - Machine type: 64 bit
 - Mupen64Plus version: svn1416
 - Plugins used: glide64

 - Armorines Project S. 2BC48B3E6F61896B9BC7BEF5205CC49C

Works fine with pure interpreter and interpreter, but not with dynarec. It
only prints on the console "PC->addr < last_addr\n"

Original issue reported on code.google.com by sven@narfation.org on 3 Oct 2009 at 11:43

GoogleCodeExporter commented 8 years ago

Original comment by richard...@gmail.com on 13 Jan 2010 at 1:18

GoogleCodeExporter commented 8 years ago 
Just as note: the problem is in amd64 dynarec's genlw()

Original comment by s...@narfation.org on 22 Sep 2012 at 7:44

GoogleCodeExporter commented 8 years ago 
The 1068th generated instruction for 2BC48B3E6F61896B9BC7BEF5205CC49C is the 
first problematic one.

Original comment by s...@narfation.org on 22 Sep 2012 at 8:54

GoogleCodeExporter commented 8 years ago 
genlh also seems to be affected. So the only way to start a game on amd64 with 
dynarec is to use INTERPRET_LW and INTERPRET_LH

Original comment by s...@narfation.org on 22 Sep 2012 at 9:56

GoogleCodeExporter commented 8 years ago 
Another way is to free the registers (using free_registers_move_start) before 
allocating new registers in genlbu, genlh, genlw. Still just a hack

Original comment by s...@narfation.org on 22 Sep 2012 at 10:34

GoogleCodeExporter commented 8 years ago 
Haven't checked why, but reg[1] should not be saved/restored on/from the stack. 
So a free_register(1) before

   stack_save_registers();
   call_reg64(gpr1);
   stack_load_registers();

avoids the problem

Original comment by s...@narfation.org on 23 Sep 2012 at 1:04

GoogleCodeExporter commented 8 years ago 
A quick check revealed that rcx (aka register 1) is the only register that is 
saved and restored. but the content before the save is:

rcx            0x492000 4792320

and after the restore

rcx            0x7ffff7e0712e   140737352069422

Ok, so the restore is broken. Checking the stack registers tells us that the 
stack is at 0x7fffffffdda8 before the call_reg64 and 0x7fffffffdda8 after it. 
So it should be fine.

Problem seems to be that we do a read_nomem -> virtual_to_physical -> 
TLB_refill_exception -> dyna_jump and just overwrites the content of the top 
most stack position with the return address (but we just saved our register 
into this position).

Original comment by s...@narfation.org on 23 Sep 2012 at 9:23

GoogleCodeExporter commented 8 years ago

Original comment by s...@narfation.org on 23 Sep 2012 at 10:20

Attachments:

GoogleCodeExporter commented 8 years ago 
Here is the patch that I would recommend for now

Original comment by s...@narfation.org on 23 Sep 2012 at 11:21

Attachments:

GoogleCodeExporter commented 8 years ago 
fixed by recent pull from ecsv's core branch

Original comment by richard...@gmail.com on 29 Oct 2012 at 4:26