[Scummvm-devel] Improving the scumm debugger

Max Horn max at quendi.de
Fri Jul 22 08:45:52 CEST 2005


Am 22.07.2005 um 15:12 schrieb Alban Bedel:

>
> Hi all,
>
> As part of my work on scummc I would be intersted in improving the  
> scumm
> debugger because currently it is a bit too limited for easy use when
> writing new scripts.
>
> The biggest problem is that one can't break in the scripts. I made  
> some
> experimental hack for this, but then one have to manualy lookup (in  
> the
> linker output) the address used by the variables, still no way to  
> step,
> etc. Some bigger work is needed.
>
> Implementing this would mean quiet some changes, so first I would  
> really
> like to hear what you all think of the following propositions and  
> if such
> kind of things would stand a chance to be accepted in scummvm ?
>
>
> Regrading break points and stepping i'm thinking of using the opcode
> 0xC1. It take an integer and a string as argument. According to cyx it
> is originaly a debug opcode and it seems to be simply ignored by
> production LEC interpreters.

I don't understand, why would you use an opcode for breakpoints (and  
note that 0xC1 is only unused in V6+ LEC games, but not in e.g. HE  
games or V1-V5 games).

Inserting special breakpoint opcodes is usually only needed when  
executing native code. In this case, we already execute scripts via a  
VM; you only have to tell it which script and which offset in that  
script it should stop; it would even be trivial to attach a condition  
to the breakpoint etc..


> The scummc compiler could add call to this op before each instruction.
> In scummc instructions are closed expression with respect to the stack
> so there shouldn't be much problem in stopping scripts at these  
> points.
> Using the string argument one could easily pass the source string to
> the debugger, removing the need to have code to lookup for source  
> file,
> etc.

You mean you want to insert the source code into the generated script  
file ? Of course you have no one-to-one correspondence between  
bytecodes and source statements. And you'd bloat the scripts a lot  
that way.

Also note, for debugging sometimes it might be nice to stop at  
"SCUMM" level statements; sometimes one needs to break at the  
"bytecode" level. Compare to source vs. asm breakpoints in GDB.
Also, it would be nice if one could use the debugger fully even if no  
additional "symbol" information is provided (be it variable names,  
source code, etc.).



>
> For symbols name the simplest is probably to store a table in the game
> file but i don't know how the LEC interpreter would react to that.
> Alternatively one can put the table in a separate file. Personaly
> i prefer not having to carry too many files around, but it would allow
> creating and using tables for existing games.

I would put all the debug stuff in a separate file, actually. For a  
release build one would want to strip the debug info anyway, and  
having it in a separate file makes that trivial. Furthermore, it  
means you have 100% compatibility with any other SCUMM VM out there  
(in theory).


Bye,
Max




More information about the Scummvm-devel mailing list