"Pavel Antokolsky aka Zigmar" <zigmar@gmail.com> wrote in message news:b9e625b70705020806l1f5d8427ua4d7938596b89a4a@mail.gmail.com...
Many responses talk about using build-in compiler's capabilities. IMHO they don't always help.
As example, in our application we want the stack trace: 1) be always activated, even in release builds sent to the customers 2) be able to print the stack trace when exception occurs
1st is much easier using custom trace, as we don't need to compile the project with debug info. BTW, that "instrumentation" doesn't look so bad in the code, and can sometimes replace comment lines, e.g: TRACE_UPDATE_CONTEXT("processing request"); At least in gcc, you don't need to have an executable compiled in debug to use backtrace(). However with optimizations turned on, inline function might not appear on stack, of course. And omitting frame
On 5/2/07, Michael Gopshtein <mgopshtein@gmail.com> wrote: pointer would optimization would also make the tracing impossible.
When compiled in non-debug mode, I think that you can't get all context info. For example, using custom stack trace you can "change" the context in some locations inside the function. Besides, those "locations" can be given descriptive names, making it easy to understand the trace.
The 2nd task is more tricky, as if you don't catch the exception in same function where it occurs, but somewhere down the stack, the "normal" stack trace is lost. In our code we keep a "history" of call stacks, and can always print the whole stack. All you need to do, is collect the stack trace and the exception throw site, not in catch site. I.e. you could make an exception class, that will retrieve a stack trace in its constructor.
This is a good solution, I agree, and can be incorporated with "custom" stack trace too.
The advantage on a native approach - is that it has zero overhead. Otherwise you introduce fairly heavy overhead into every function call, plus you can't get a stack entries in third-partly libs.
The overhead is no heavy, you also don't need to put trace functions at every place in the code, just in major functions. In our product the stack trace didn't cause any noticable regression in performance (and preformance is very important for us).
I'm actually working now on something even more interesting - on implementing stacktrace with function arguments. I mostly sure, however, it could not be ported on most platforms, because the trick I'm trying to use - is to extract function frame description from DWARF debug information from within the executable itself. :)
That could be interesting too, you can also handle cases of pointer parameters - by storing the data.
-- Best regards, Zigmar _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost