TorqueScript Debugging API problem
by J "hplus" W · in Torque Game Engine · 09/17/2006 (3:02 pm) · 8 replies
There's a problem in the TorqueScript debugging API.
In most kernel debugging APIs, when the targeted program loads a new piece of code, the debugger is synchronously notified, and has a chance to set breakpoints in the new code, before that code is made available to the debugged application.
However, in the TorqueScript debugging API, there is no facility for notifying the debugger of scripts being loaded, as they are loaded. Instead, the debugger has to discover scripts after the fact, the next time the program stops. This has two problems:
1) you can't set a breakpoint in an un-loaded script file, and expect that breakpoint to then be hit when the script is loaded and the function called
2) stopping becomes slower (from a GUI point of view), because the debugger needs to get the list of all loaded scripts and compare it to the list it already knows about
In most kernel debugging APIs, when the targeted program loads a new piece of code, the debugger is synchronously notified, and has a chance to set breakpoints in the new code, before that code is made available to the debugged application.
However, in the TorqueScript debugging API, there is no facility for notifying the debugger of scripts being loaded, as they are loaded. Instead, the debugger has to discover scripts after the fact, the next time the program stops. This has two problems:
1) you can't set a breakpoint in an un-loaded script file, and expect that breakpoint to then be hit when the script is loaded and the function called
2) stopping becomes slower (from a GUI point of view), because the debugger needs to get the list of all loaded scripts and compare it to the list it already knows about
#2
OK, I'll add that to the documentation page. (I'm using 1.4 "plain" by the way) I'm writing from the point of view of an external debugger author, btw.
That almost gets you all the way there. Unfortunately, the debugger still has to re-load the list of available files each time you hit a stop. That can be worked around so it doesn't block the responsiveness of the debugger, but it's still annoying (especially when you have hundreds of files loaded, and have to diff the loaded set to the new file set).
09/17/2006 (6:55 pm)
Quote:the TelnetDebugger internally takes care of applying them to newly loaded code.
OK, I'll add that to the documentation page. (I'm using 1.4 "plain" by the way) I'm writing from the point of view of an external debugger author, btw.
That almost gets you all the way there. Unfortunately, the debugger still has to re-load the list of available files each time you hit a stop. That can be worked around so it doesn't block the responsiveness of the debugger, but it's still annoying (especially when you have hundreds of files loaded, and have to diff the loaded set to the new file set).
#3
The main thing to avoid as I'm sure you're aware is making the debugger stubs so complex they have to be debugged themselves. ;)
09/18/2006 (1:21 am)
If you care to add some messages to make that more efficient (and they're reliable, ie, if you connect in the middle of things) I'd be glad to merge them into trunk.The main thing to avoid as I'm sure you're aware is making the debugger stubs so complex they have to be debugged themselves. ;)
#4
09/18/2006 (1:44 am)
Right... currently the TelnetDebugger knows when a codeblock is loaded. It is easy to have a new message which it sends the debug client when that happens.
#5
09/18/2006 (8:04 am)
Yes, all you need is a "LOAD filename" notification when something loads. Someone connecting in the middle of the game would still use the file list query to get the baseline.
#6
09/18/2006 (4:36 pm)
You do actually get those "loaded file such and such" console messages... but having the telnet debugger do LOAD would be smart. Look forward to your patch. :)
#7
http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=11297
09/19/2006 (9:08 am)
OK, that wasn't even hard. Torsion seems to still work after adding this notification; that's probably helpful to some :-)http://www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=11297
#8
09/19/2006 (10:11 am)
#2712, noted for merge. 
Associate Tom Spilman
Sickhead Games