Skip to content

WIP: Initial proof of concept for debugger

jdavidberger requested to merge jdavidberger/cmake:debugger into master

Several due diligence things haven't been done yet for this merge request (tests / clang format / platform checks / etc). This merge request is mostly to get a feel for how much support there would be in adding this sort of feature. And obviously, if this is better moved to the issue tracker or something let me know.

This is a proof of concept for a step-through debug option on CMake proper. I've found myself wishing one existed for a while now; before resorting to just throwing MESSAGE in all over the place. This functionality would also be helpful in sussing out list / string conversion issues and the like. The implementation isn't that tricky; the real question is whether or not the community is interested enough in this kind of feature to make it fully fleshed out; and whether there is enough interest to work its way into the various UI tools.

This implementation is logically split into two parts:

  • The debugger core (cmDebugger) which hangs off of 'class cmake' and various events get forwarded into -- namely right before executing a command ('PreRunHook') and when a fatal error happens ('ErrorHook').
  • The debug server, which is modeled and reuses the event loop in cmake server mode. Currently the only debug server (cmDebugServerSimple) is one that reads from stdin and prints to stdout. The idea though is mostly to expose it via pipes / sockets for actual UI clients.

To try it, build this branch and run cmake as normal, except pass in '--remote-debug=stdin'. This will launch cmake, and immediately be paused at the first line; and a prompt should appear. Commands are only processed after you hit enter. The command reference is meant to line up with gdb.

Current supported commands are:

  • c - Continues if you are currently paused
  • b - Breaks if you are not currently paused (Should be replaced with SIGINT; there were issues with that though)
  • s - Step
  • bt - Prints the current backtrace
  • print - Prints the current CMake variable if it is defined
  • info br - Prints info on all breakpoints
  • br : - Break at the given filename at the given line. Any file which contains the substring given will match.
  • br - Break at the given line in the current file
  • clear <bp_id> - Delete the breakpoint at the given id. The ID is printed when you do 'info br'.
  • clear - Delete all breakpoints

Areas that still would need work:

  • Smarter breakpoint handling -- optional regex, faster checks to see if a bp exists at the current location, some mechanism to detect if the given line exists, conditional breaking.
  • Full expression evaluation
  • Watchpoints
  • More 'info' subcommands -- 'info targets', for instance, would be really useful. Ditto for properties.
  • Frame support; functionality to list all frame variables / global variables
  • Probably some fast and loose-ness going on with race conditions that needs to be cleaned up.
  • An actual remote debug protocol.

The last point I've done some looking into and couldn't find any protocol used for interpreted languages to communicate with a debugger in any kind of standard way. Possibly something could be done to use V8's protocol though, which could be interesting, but honestly this really begs for input from IDE / tool providers as to what makes the most sense. Leaving in and expanding on the stdin / out is mostly useful for reference / debugging I imagine; I don't think most people would use it directly.

Merge request reports