[ Start > PikeDevel > PikeDebugger ] [ Edit this Page | Viewing Version 10 ]

Work on permitting pike code to be debugged interactively is underway, and currently exists as a rough proof of concept in branch bill/debugger-concept. The debugger requires pike to be compiled with --with-debug and can be enabled using --debugger option to pike, with enables a hilfe server on port 3333

Current features of the POC

  • Multiple breakpoints may be set and cleared independently.
  • Hilfe interface
  • Backtrace viewing
  • Frame stack browsing (as part of backtrace frames)
  • View locals (but names are not resolved)
  • Modify locals
  • Single stepping
  • Continue

    Things that need to be done

  • Local name calculation
  • Pass current thread to debugger engine
  • Allow the debug session to stop execution without waiting for a breakpoint
  • A programmatic interface to the debugger
  • Step-over, in, return, etc. These require understanding of code structure
  • Watchpoints?
  • Efficiency improvements?
  • Work to not require RTL debug
  • Make ports configurable

    Example of a debugging session:

$ telnet localhost 3333
Connected to localhost.
Escape character is '^]'.
Welcome to the Pike Debugger.
> object bp = Debug.Debugger.add_breakpoint("/path/to/file.pike", 22);
> object bp1 = Debug.Debugger.add_breakpoint("/path/to/file.pike", "/path/to/included_file.h", 2);
> bp->enable();
> bp1->enable();
> go
Breakpoint on /Users/hww3/bpt.pike:22
> backtrace;
(1) Result: ({ /* 4 elements */
                backtrace_frame(/Users/hww3/pike2/build/darwin-16.7.0-x86_64/master.pike:4148, _main(), Args: 1),
                backtrace_frame(-:1, `()(), Args: 1),
                backtrace_frame(/Users/hww3/bpt.pike:14, doit(), No args),
                backtrace_frame(/Users/hww3/bpt.h:2, whee(), Args: 1)
> backtrace[-1]->locals();
(4) Result: ({ /* 3 elements */
> backtrace[-1]->set_local(1, "bar");
(5) Result: 0
> backtrace[-1]->locals();
(6) Result: ({ /* 3 elements */
> step
Breakpoint on /Users/hww3/bpt.h:2
> go

Some thoughts about an api_

The programmatic API would probably need to be at least partially asynchronous, as events may occur at any point, and not necessarily in response to a request from the debugging client. An example would be one or more breakpoints being reached.

It seems as though it will be necessary for certain aspects of the api that deal with evaluation, variable assignment and such, to operate in a "semi-hilfe" mode, where expressions are passed over the link and evaluated in the debugger. Otherwise reference-type values would always be new literals, and it would not be possible to, for example, replace a value with a mapping that was defined elsewhere in the context being debugged.

__Some notes about optimization

Powered by PikeWiki2

gotpike.org | Copyright © 2004 - 2009 | Pike is a trademark of Department of Computer and Information Science, Linköping University