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
> 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
> 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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk