[boost] Re: Stack tracing (was: improved assertions?)

From: Ted Byers (r.ted.byers_at_[hidden])
Date: 2002-06-13 10:57:01

> What the StackWalk API will allow is the actual walking of the CPU call
> stack, which gives us at least the addresses of the call stack.  The
> Nies/Byers approach is dependent on *manually* adding "stack" information.
> They do this by pushing the stack information onto an exception object as
it
> is re-thrown from one catch-handler to another.  The main drawback to this
> approach, IMO, is that it forces every function that wants to be included
in
> the stack dump to have a try...catch that manually adds its own stack
> information.  Here's the quote from the end of the CUJ article: "Traceable
> exceptions are most effective when the software trace coverage is
maximized.
> Towards this goal, every possible method should minimally have a default
> outer try/catch block with a 'CommonExcep' catch clause that invokes the
> 'push' method."
>
Quite right.  And, while Nies' article provided an initial spark, my
implementation is much easier to use.  Unlike Nies' exceptions, I don't need
to develop a new class for each exception class to be handled, and I have a
handful of macros that makes it trivially ease to add the requisite
try/catch blocks to each function that needs to be included in the trace.

>   Use the logical address to look up a symbol name in a map file
>
This assumes you want to generate and distribute a map file for your
executable and DLLs.  I'm not saying this is bad; just it is one extra thing
that needs to be done, and carries some cost.

> However, there are several restrictions and strange behavior that I have
> bumped into getting this to work with Borland:
I am interested in learning more about what you have done with Borland;
particlarly what APIs you used and how.

Cheers,

Ted