> Since you can call target process functions from GDB, it would be interesting to have some form of "emergency dump" function you could call, to get out the data even though the process as a whole has hung.

I have seen these before in some server products. Not necessarily printing out everything you needed to know, but to give some important internal stats, etc. Functions not called from anywhere in code that cause the process to output stuff if called from a debugger.

> This would have the benefit by being implemented in the target process itself, so it could of course have full knowledge of the data structures and so on. It could potentially be way better than a raw (manual) memory-level inspection.

So it is possible, as I have worked on products that do this, to have a custom debugger that knows everything about the process.

You write the program in such a way that you avoid dynamic allocation, almost everything is implemented in predefined global buffers of one sort or another, and then the debugger knows where everything is at compile time. This may seem inflexible and painful to code, but if you are in a highly resource-constrained environment in the first place then it has some advantages.

You can then use the debugger to watch and modify absolutely everything, at runtime or from a memory dump. It can be quite powerful.