1

I would like to know if it is possible to build tcl scripts debugger using Tcl Library API and/or Tcl internal interfaces (I mean if they contain sufficient data to do so). I've noticed that existing tcl debuggers instrument tcl scripts and work with this additional layer. My idea was to use Tcl_CreateObjTrace to trace every evaluated command and use it as a point to retrive callstack, locals etc. Problem is that it seems that not every information is accessible from API at a time of evaluation. For example I would like to know which line is currently evaluated but Interp has such info only for top evaluations (iPtr->cmdFramePtr->line is empty for procedures' bodies). Anyone has tried such approach? Does it make any sense? Maybe should I look into hashed entries in Interp? Any clues and opinions would be appreciated (the best for Tcl 8.5).

Bogdan
  • 984
  • 8
  • 16
  • for [memory debug](https://www.tcl.tk/man/tcl8.6/TclLib/TCL_MEM_DEBUG.htm) – Yann Jun 16 '14 at 11:22
  • @Yann I don't want to debug Tcl interpreter. I want to debug Tcl scripts like TclPro or Komodo (based on TclPro) do. – Bogdan Jun 16 '14 at 11:25
  • Why would you find overloading `proc` and using `trace` to build a debugger unacceptable? – slebetman Jun 16 '14 at 12:42
  • Note that most tcl debuggers, although they "instrunment" tcl scripts by overloading proc (and maybe set) and tracing everything don't actually require any modification to the scripts. "Instrunment" here means something completely different than other languages. – slebetman Jun 16 '14 at 12:44
  • @slebetman I didn't say it's unacceptable. It's just unusual (are there other scripting languages debugged this way?). I'm curious if I can achive the same without instrumenting, and probably non-instrumented way would be faster and give more functionality, for example you wouldn't need to choose which script to instrument. – Bogdan Jun 16 '14 at 14:04
  • I think you're missing something. You're not "instrumenting" any script. Instead you write a debugger in pure tcl (call the file debugger.tcl if you like) which accepts a tcl script to execute. Hey, that sounds exactly like how you'd use gdb! In fact you don't even need to write one from scratch. You can always use the venerable RamDebugger: http://wiki.tcl.tk/3912 – slebetman Jun 16 '14 at 14:40
  • @slebetman Well, definitely I don't understand something. Please, open RamDebugger, define simple script with some proc, and in 'Utilities' menu choose 'View instrumented file P' and 'View instrumented file R'. Clearly every line of the script was re-written to call additional proc to get info about file/line and provide steps. I don't want to parse and run re-written script. Tcl engine gives me native possibility to stop before every command, thus I just want to read some info about current evaluation point. Question is: does this data exist in Tcl core at time of evaluation? – Bogdan Jun 16 '14 at 15:14

1 Answers1

0

Your best bet for a non-intrusive debugging system might be to try using an execution step trace (called for each command called during the execution of the command to which the trace is attached) with info frame to actually get the information. Here's a simple version, attaching to source so that you can watch an entire script:

proc traceinfo args {
    puts [dict get [info frame -2] cmd]
}
trace add execution source enterstep traceinfo
source yourscript.tcl

Be prepared for plenty of output. The dictionary out of info frame can have all sorts of relevant entries, such as information about what the line number of the command is and what the source file is; the cmd entry is the unsubstituted source for the command called (if you want the substituted version, see the relevant arguments to the trace callback, traceinfo above).

Donal Fellows
  • 133,037
  • 18
  • 149
  • 215
  • Unfortunately `info frame` gives only information about relative line inside particular `proc`, there is no info about absolute frame position in script. Moreover, I've dug a little in Tcl Core and it seems that there is no info about `proc` position at all at evaluation time, so instrumentation seems to be the only way to do fully functional debug tool :( – Bogdan Jun 23 '14 at 08:40