"Pavel Antokolsky aka Zigmar" <zigmar gmail.com> wrote in message
news:b9e625b70705020806l1f5d8427ua4d7938596b89a4amail.gmail.com...
> On 5/2/07, Michael Gopshtein <mgopshteingmail.com> wrote:
>> 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
> 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:
> htt
p://lists.boost.org/mailman/listinfo.cgi/boost
>
_______________________________________________
Unsubscribe & other changes: htt
p://lists.boost.org/mailman/listinfo.cgi/boost
|
