Subject: Re: [boost] Interest check: Boost.Debug
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2009-06-06 03:14:51
Zachary Turner wrote:
> 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):
I've started this work as part of Boost.Test functionality. I'll be
happy to offload this to you, but please make sure I can reuse it from
inside Boost.Test. Most important consideration should be portability.
Please see boost/test/debug.hpp for details.
> - Loading debug info either for the currently running executable or from an
> offline executable
> - Printing human readable stack traces from a running program
Yes. I never got to finish it. We've got at least 3 different underlying
runtimes to support.
> - Dumping stack traces to a file in release mode. In this case it's usually
> just a dump of the entire stack in binary.
> - Matching dumped stacks from step 3 to debug information offline to get
> post-mortem information.
> - 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)
> - Iteration of loaded modules
> - Check whether debugger is attached
I named this function boost::debug::under_debugger. It works in number
scenarios, though *nix implementation is rather 'hacky'.
> - output stream that goes to the debugger console, and is not visible in the
> debugged process. I'm not sure about the feasibility under non-windows
> platforms (it's very easy in windows), but I would think that if it's
> possible to figure out the PID of the process debugging you, that it should
> be possible to send output to their stderr which should achieve the same
> effect.
> - launch process under a debugger and receive basic types of debugging
> notifications.
I opted for interface which allows developer to tell that the debugger
has to be attached here. I named this function boost::debug::attach_debugger
I also have following functions in this module:
debugger_break - cause program to break execution in debugger at call point
detect_memory_leaks - switch on/off detect memory leaks feature
break_memory_alloc - cause program to break execution in debugger at
specific allocation point
set_debugger - debugger setup
If you serious about finishing this work you can count on my help both
with transition on my code and review process in Boost.
Regards,
Gennadiy