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 ...
Read More →
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 ...
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 ...
Read More →
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 ...
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:
Read More →
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 ... |
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 →
~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 ...
Read More →
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 ...
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 →
Thanks all!
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 →
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