Show HN: Hook – a simple graphical C/C++ runtime editor (opens in new tab)

Optimising IR without dropping debug info is difficult. I don't believe it to be intractable, some of the Sony developers are active in improving this for LLVM. Debug info is roughly a bunch of side tables of data from which one can recompute values which were in the original program and are not in the executing one. I would speculate that a compilation mode which treated any degradation of that as a miscompile could be done with minor to no runtime cost, at serious engineering cost.

Perhaps easier would be to restructure the program so that specific variables are always available to the debugger. Deliberately hoist them to escaped global variables, roughly.

The other interesting line of attack here is a JIT. The students probably don't change all the parameters simultaneously. Call graph walk + incremental compilation of parts affected by a given variable is probably tractable. A sibling mentioned hot code replacement, that's a similar sort of hack (you block function inlining, pad functions with some nops, then overwrite in place if the new definition fits in the space).

Thanks for the link, interesting stuff.

<https://blog.voxagon.se/2018/03/13/hot-reloading-hardcoded-p...>

In other words, rather than having a graphical interface for tweaking values at runtime, you interface with it the same way you normally would—by changing the constants in the original source file, but the difference between the ordinary stop-and-recompile way of doing it is that the changes get picked up live, so there is no stop-and-recompile. (This isn't exactly novel; webdevs have had hot code reloading to various degrees for a while, but the conventional static languages folks have generally needed to rely on support in sophisticated IDEs to get the same thing, and many end up going without.)

For those who want the graphical control panel, I suppose you could do the complement: when a value is tweaked in-game, it could overwrite the existing value in the source file so you don't have to tweak in-game and then manually copy them out to source once you've landed on the values you like.

Is it the include of LLDB.h?

In my case, I went to implement this for Windows, but bit more advanced with inline scripting support. Basically, you insert a snippet anywhere in the code that can call various functions and one of them is `view()` which will show all locals (or a chosen object out of scope) in a Visual Studio window (it's a VS extension [0], website [1]). Calling it again will update the view with the new state. The scripting language underneath is Angelscript and it understands symbols inside your entire project (e.g you could do `view(Namespace::g_variable)` or even call functions from the program etc. The snippet hook is then JIT'ed into the target function by relocating it using info from the PDB. This took me ~1y to implement, and it's still a research phase project.

[0] https://marketplace.visualstudio.com/items?itemName=donadigo...

[1] https://d-0.dev/

The best experience I've had with this kind of thing has been Godot. Not only do you get to tweak values at runtime, you can also change the code at runtime and see changes reflected live. It's so awesome being able to hit a breakpoint in a running game, step through some code, change the code, and then continue stepping to see the changes.

This is generally a tool you would likely need to build into a game regardless for exactly the reason you mentioned, rebuilding to change gameplay variables isn't exactly a great experience.

I personally just use a simple terminal that I can open and close to adjust variables but eith hoe easy imgui is I don't see any reason to not do a gui window for that.

This looks cool but I'm not sure how it is especially superior to functionality that is easily available through your favorite debugger (note: I'm speaking from a standpoint of Qt Creator + gdb; YMMV depending on your IDE/debugger setup), especially given that Hook seems to be mainly targeting macOS.