2009/6/2 Zachary Turner <divisortheory@gmail.com>
In my spare time I have been working on a library to analyze debug information from a running program. It either already does, or I would like to have it before I'm done, support all of the following (I'm sure there are plenty of other neat additions that I haven't thought of):
This sounds extremely useful, we've developed quite a bit of in-house production code (unfortunately for Windows as well so can't help with portability) and it helps a great deal in large-scale software.
- Loading debug info either for the currently running executable or from an offline executable
Care to elaborate a bit, I don't follow exactly. How is this useful compared to attaching a debugger?
- Printing human readable stack traces from a running program
IMO getting a stack-trace really quick, and defer the print-out (using the dbghelp on windows for instance) until the user requests it would be more useful than printout only. Like: boost::debug::stack_trace foo() { return stack_trace(); ] boost::debug::stack_trace bar() { return foo(); }; main() { std::cout << bar(); } It could then also be bundled together with boost::exception without a huge performance impact at throw site, and without having the exception object grow unhealthy big.
- Dumping stack traces to a file in release mode. In this case it's usually just a dump of the entire stack in binary.
Where to dump the trace is better left to a logging library (there are two submissions to boost atm I think) or to the choice of user.
- Matching dumped stacks from step 3 to debug information offline to get post-mortem information.
Same as above.
- Assuming symbol information is loaded either for the running program or an offline program, format a block of memory in a human readable format to print the structure of the memory (for example, display member values of a class with field names, given a block of memory representing an instance of the class)
Care to provide an example here?
- launch process under a debugger and receive basic types of debugging notifications.
What kind of notifications are you referring to?
That being said, is it worth it to tackle something like this or should I just not worry about the generality and keep working on it for personal use only?
It's always worth worrying about =) I think the problem can be divided into: 1). Collect information (thread context, stack-frames, stack-size, memory load and other useful diagnostics). 2). Output information (using a symbol engine for stack-trace, such as dbghelp) 3). Support bundling with boost::exception, to allow for the useful feature of easily dumping where from an exception was originally thrown, if a stack trace was added to the exception by user. I do not think it should provide a logging facility, since that's quite a task by itself. Regards, Christian