GIF_LOG segfault in gsRead32 function

[GoogleCodeExporter]

I switch on GIF loggin on Linux host and run Eternal Poison. And, just a
bit surprise, it segfaulted in GS.cpp:660 at line:

GIF_LOG("GS read 32 %8.8lx, at %8.8lx\n",
*(u32*)(PS2MEM_BASE+(mem&~0xc00)), mem);

Well, it's just normal to fault here, because PS2MEM_BASE+(mem&~0xc00) is
very big value, when I cast it to double I'v got -1078284268 (so it's
overflow).

And just a bit surprise, the next line is
    return *(u32*)PS2GS_BASE(mem);
so I could not understand, why logging use different pointer structure,
than return (may be it have a meaning, or may be just a history incompat).
And gsRead64 have normal log. So I propose to normalise all 4 read
function's loggin.

Original issue reported on code.google.com by Zeydl...@gmail.com on 15 Nov 2008 at 8:12

Attachments:

• gsRead.diff

[GoogleCodeExporter]

Thanks for finding that.
I have noticed too that *many* LOG entries are very out-dated.  The IOP Counters
(using PSXCNT_LOG) for example are almost completely non-functional as well...
dumping the values of now-unused variables and stuff.  I'm fixing them up now,
finally. :)

If you spot any other bogus LOG uses, feel free to upload the patches as Issues 
and
we'll apply them asap.  Getting LOGs back in shape will help in future emu 
feature
additions, I'm sure.

Original comment by Jake.Stine on 17 Nov 2008 at 4:55

• Changed state: Accepted
• Added labels: Priority-Low, Type-Enhancement
• Removed labels: Priority-Medium, Type-Defect

[GoogleCodeExporter]

Finally applied this patch. :)
The funny part is that I went to look through the gs.cpp because of this patch, 
ended
up getting myself into a bunch of MTGS changes, and then forgot to apply the 
patch still.

Original comment by Jake.Stine on 20 Nov 2008 at 12:23

• Changed state: Verified