Boost logo

Boost :

From: Victor A. Wagner, Jr. (vawjr_at_[hidden])
Date: 2002-06-20 16:01:30


I hope I didn't give the impression that there was a "standard" way to do
it. The code will be definitely system dependent.

It's been a while since I was on either a compiler or library team, so
giving a hard example for any currently used architecture would be beyond
my immediate abilities. I do recall writing them, and that they were NOT
difficult (on the same order as "stack unwinding", but probably simpler)
and generally took one programmer somewhat less than a week given that the
compiler team was available for all the 'dirty little details' about stack
frames, etc. Of course, these days, there are supporting databases to
describe the contents of the frames (for the debuggers) which we'd want to
use and that would likely up the programming effort required.
At Thursday 2002/06/20 13:24, you wrote:
> >
> > Think how _simple_ it would be to provide a "stack trace" if the stack
>were
> > still intact!!
>
>Maybe it is simple, IF you know how to do it. Can you tell me how to do it,
>perhaps with some sample code that I could call a) on a failed assertion,
>and b) at the time I am catching MS' structured exceptions? I saw the
>documentation for the function StackWalk, but without some sample code to
>show how to use it to produce a trace, I am having trouble figuring out how
>to use it. And, of course, that won't help me when I move toward developing
>for Linux.
>
>But, since C++ exceptions are not yet involved in these two cases,
>presumably the stack would still be intact at that time. Right?
>
>Cheers,
>
>Ted
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Victor A. Wagner Jr. http://rudbek.com
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk