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

From: scleary_at_[hidden]
Date: 2002-06-13 13:05:23

> From: Ted Byers [mailto:r.ted.byers_at_[hidden]]
> >   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.

My current (limited) implementation will output the logical address in the
absense of a map file; this allows error reporting of the logical address,
which one could manually look up in a map file.  So you don't *have* to
distribute it (you would still have to generate it, though).

> > 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.

For walking the stack, I used the "standard" StackWalk from dbghelp.dll. The
stack-walking and virtual-to-logical address translation is about the same
as you would find for any MSVC-based solution (there are a few on the 'Net).

The symbol lookups I wrote myself; map files are located by replacing the
filename extension of the "logical address module name" with ".map", and
read in using a hand-written parser.

I briefly toyed with the idea of hacking into Borland's debug info, but
tossed it because:
  . This would be more time consuming than a map file parser
  . Symbolic traces would require programs to be compiled in debug mode
  . It could change with any future release of the compiler
Anyway, the "optional map file" roughly (very roughly) corresponds to
Microsoft's "optional pdb file".  A PDB file, just in case anyone doesn't
know, is a "program database" which contains debug symbols (and who knows
what else...) that can be used to look up symbols if present.

        -Steve