RemedyBG's Debug Protocol
x13pixels

RemedyBG's debug-protocol for requesting and receiving data has now been fleshed out. The way it works is pretty straight-forward and was inspired by Casey's discussion of debugger architecture from a while back.

To open a new inspector, the user makes a single call into RemedyBG. This call takes an inspector expression along with a user provided callback that gets triggered in a few different cases.

First, we'll talk a little bit about the inspector expression strings themselves. Briefly, an expression is structured as

{expression:field_1;field_2;...;field_n}

where 'expression' can be any of the pseudo-expressions (%callstack, %modules, %threads, %watches, %breakpoints, %registers, or %processes), a C-style array, or a linked-list in which the expression is augmented with the name of the field to allow traversal as

{expression(next_field);field_1;field_2;...;field_n}

The pseudo-expressions act as if they were C-structs with their own fields. For example, %call

Read more

Symbol file acceleration structures
x13pixels

The last couple of days I've been working on RemedyBG's call-stack display and realized that the acceleration structures that are baked into the PDB may be useful to Microsoft for linking but they sure suck for a debugger.

For instance, there is a hash-table (chained for resolving collisions) that you can read from the PDB (after "decompressing" and fixing up ptrs) for both public and global symbols. However, the symbols they resolve to are either i) symbols with only a name and location (section/offset) -- not detailed enough (e.g., we want the function's type, #arguments, info on FPO optimizations, etc.) -- or ii) a reference into the sections symbol table which actually does have this information. Though these more detailed symbols, the ones you actually want, don't have any meaningful baked data structures for accelerating look-ups.

I also noticed that VS2017 adds duplicate records (e.g., WinMain multiply added) to the symbol stream (sometimes with incorrect segment offsets)

Read more

Update: Apr 2018
x13pixels

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:

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

Read more

Update: Jan 2018
x13pixels

I finished the step-over and step-into functionality today. Next up is set-next-statement and run-to-cursor which are just simple extensions of the work I did today. After that, I am going to start on the callstack display (using the UI code I wrote a while back).

~x13pixels

Read more

The Day after Patreon Imploded: scraped recap of my posts
x13pixels

Bye bye Patreon. All updates to RemedyBG will now be made here. Here is a recap of progress made throughout 2017:

6/18/2017

I made a good bit of progress on the PE/PDB parser used for symbol lookup, file/line number information, and so forth. At a high level this included:

  • Extracted necessary information from the PE header to determine starting address (e.g., WinMain) along with section information

  • Completed reading the containing multi-stream file format used by PDBs

  • Reading the PDB header stream (PDB signature, age, version information, and so forth)

  • Began reading the debug information stream for obtaining a mapping between relative virtual address and the contributing module. The initial goal here is to have a look-up from current instruction pointer address to source and line number and tie that back into the debugging engine.

6/21/2017

People have asked if RemedyBG will support Linux. The answer is no. Check out Lysa

Read more

November Coming Fire
x13pixels

Four months ago I wrote, "...it will be three or four months at this pace before something is ready for release". November is here and although I do not have something ready for release I have been hankering to start up some streaming, video-casting, or the like to show off what has been done to date. Began playing with OBS and such to see what I can throw together. Stay tuned for more information soon.

Thanks all!

Read more

Updates and such
x13pixels

Hello all.

I just wanted to let everyone (who cares) know that RemedyBG is coming along well and at a nice, steady pace. A little bit of time each night to tend to the project goes a long way...

That said, it will be three or four months at this pace before something is ready for release. Writing everything from scratch is enjoyable and enlightening but also takes additional time. The price paid, though, will be worth the effort in the end.

-- George

Read more