[Scummvm-devel] ps2 gdb & COMI buster

[sunmax at libero.it]

Hi ScummVM fellows!

;-)

Ok, ok. Let's proceed by steps:

1. I was eventually able to get gdb to work with PS2! ;-) ;-) ;-)

Well kind-of. It all boils down to the fact that on my hw modded PS2s
+ ToxicOS, the MIPS "break" instruction (kind like the "int 3" on x86)
is swallowed somewhere in a limbo (still working on that!) so it never
triggered the breakpoints on gdb side...

With a list of MIPS exception and their UNIX conversions at hand,
I decided to replace it with a "trap" (teq $0, $0 : always true).
Both exceptions ("0x09" and "0x0d") convert to SIGTRAP anyway.

It's an unbelievable hack, but it works. I just cannot add breakpoints
interactively from gdb, but I can insert them at compile time as func
breakpoints() - what really matters: we can now step in the code, print
vars and when there is an illegal memory access or TLB exception we get
prompted with a friendly gdb session ;-)

Since MIPS have no "step" instructions I resorted to the same trick,
implementing it a series of "traps" inserted on the fly, now I know
by heart that "break" is 0x0000000d and "teq $0,$0" is 0x00000034 !

Now, we just need to be able to insert breakpoints on the fly and to
switch between threads, then debugging on PS2 is going to be a breeze
and not anymore the martyrdom of days.

Next step would be to upgrade the tools (gcc, binutils, etc.), but
I have to get back to ScummVM 0.14.0 now!


2. As a first tangible result of ps2 gdb usefulness, I was able to
trace the infamous COMI stack corruption. It's in "grabOverlay".
The buffer passed to the function is undersized for the copy,
so hell breaks loose.

_screen.pixels in ThemeManager is alloc in ThemeEngine::setGraphicsMode

setGraphicsMode is called in a chain from:

 - GUIManager ctr - loading & initing a new theme
   (see bt0.log)

 - ThemeEngine refresh - when the launcher dialog is put on screen
   (see bt1.log)

Now on PS2 up to here all buffers are 320x200*bpp, eg. _screen.pixels
is 320x200x2.

Now when we start COMI, a bigger game buffer (640x480x1) and overlay
(640x480x2 [*]) are allocated with new width and height that are
used in grabOverlay to copy the overlay to _screen.pixels which is
still just 320x200x2 -> KABOOM!  [see bt2.log]

[*] it's actually possible that this is wrong and I should keep it
320x200x2, this would explain why the popup menu shows only in the
top-left quarter of the screen - I will soon know ;-)

Suggestions are welcome! Thanks.

Now,

a) Is this the expected behavior?

   I mean expecting that overlay size shouldn't be modified anymore
   after we put the game launcher on screen.

b) Otherwise we should make sure the _screen.pixels in ThemeManager
   is re-allocated to match the new overlay size when a backend in
   OSystem*::initSize is changing the overlay size.
   
Is that something the backend should do on its own? I mean calling
ThemeEngine::setGraphicsMode when the overlay size changes as a
consequence of a screen res change?

I started working on trunk for 0.14.0, it compiles but so far it's all
pitch black. It surely extends the life of my LCD TV, but is not very
exciting. It probably still need dome fine tuning... anyway it's going
to be much easier now with gdb!

The only serious open issue is the corruption on scummvm.ini, which is
probably due to out of sync caching when writing back the config file
(if that proves to be the cause, we could just disable caching on R/W
files on PS2 and leave it on only for the big RO files (like *.bun)
where is really needed).

Talk soon!
 -max
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bt0.log
Type: application/octet-stream
Size: 1427 bytes
Desc: not available
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090708/dcd8617d/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bt1.log
Type: application/octet-stream
Size: 941 bytes
Desc: not available
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090708/dcd8617d/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bt2.log
Type: application/octet-stream
Size: 849 bytes
Desc: not available
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090708/dcd8617d/attachment-0002.obj>