Re: [boost] Interest check: Boost.Debug

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