[Scummvm-devel] Re: Improving the scumm debugger

[Alban Bedel]

On Fri, 22 Jul 2005 17:44:26 +0200
Max Horn <max at quendi.de> wrote:


> > 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).

Sure the selected op code would depend on the target interpreter.
Sorry but i didn't mentioned that i'm only targeting LEC v6 atm.
 
> 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..
 
Sure it's not the only solution. Carring 100's of offset doesn't sound
much better to me. But I'll probably look into that too.
 
> > 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.

As said "scummc instructions are closed expression with respect to the
stack". This mean that such expression can potentialy contain a lot
of basic scumm operations and do match to a clear simple expression in
the source like: x = ((58*y)+34*z)/a


> And you'd bloat the scripts a lot  
> that way.

Yep, on the other hand it take bloat out of the debugger and the size
of the game during developement doesn't matter much.


> 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.

It's something that wouldn't be very intersting for me. If the
compiler generate broken code i have to analyse it by hand anyway.

However if some would find that useful i could investigate it too.
But with the multiple threads sharing the same stack, and the
debugger running "outside" of the main loop, that would need
some extra care to restart the correct script.


> 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.).

I have no plan whatsoever to remove anything that currently exist or
is doable. Just adding new stuff or extanding what there is.
 
> >
> > 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).

Good point.

	Albeu

PS: Please stop CC'ing me.