Update: Apr 2018

x13pixels  —  5 months, 2 weeks ago [Edited 0 minutes later]
Holy smokes it is April 2018 already! A lot of time has passed since a serious update to RemedyBG for various personal reasons. I decided to thwart this idleness by taking a "vacation" day today to work on the debugger.

Since the last update I've put together a test harness for RemedyBG-Vim that accelerates, well, testing. Having to build, reload Vimscript (if necessary), start the process, run to a breakpoint, verify results, and so on, was getting to be quite tedious.

A simple RemedyBG-Vim test script looks something like:

1
2
3
4
5
6
7
8
debug-new-process tests\debug-new-process_command_args\a.exe "{'args': '-o test.h --test'}"
.expect % "{'status': 'Status_Ok'}"
continue-execution
.expect % "{'status': 'Status_Ok'}"
.expect @ -o
.expect @ test.h
.expect @ --test
.expect # "{'type': 'exit-process', 'exitcode': 0}"


From Vim, commands can be sent to the remedybg_vim process via standard-in. In the test script these are lines containing a RemedyBG-Vim command along with arguments packed into a JSON string (note that JSON is only used for the Vim integration; JSON is not, and never will be, used in the formal RemedyBG API). The immediate result from the command, typically a status, is received back via standard out. The ".expect %" you see in the script above is used to check against this result.

Some examples of RemedyBG-Vim commands include

  • debug-new-process
  • continue-execution
  • terminate-process
  • add-breakpoints-at-function
  • add-breakpoint-at-source-location
  • step-over
  • step-in
  • step-out
  • etc.

  • Other parts of the integration with Vim include writing contents of OutputDebugString into a buffer. These are checked with ".expect @". Also, RemedyBG-Vim can send a message whenever an event occurs (breakpoint was hit, process is terminating, and so forth). These are validated with the ".expect #" statement.

    That's all I have for now. Take care all.
    #15407
    x13pixels  —  4 months ago
    Currently: fixing a bug in step-in whenever the /INCREMENTAL switch is specified. According to the documentation, "May contain jump thunks to handle relocation of functions to new addresses". Presently, stepping into a function stops at the jump table and not the function itself.
    Log in to comment