Re: [boost] Review Manager needed for stacktrace library

What about giving access to the list of ids, RVAs relative virtual address? This way this could be saved in the case of a release build that doesn't have the debug information and then paired external to the program with pdb/dwarf file to reconstruct the stack trace?

________________________________
From: Boost  on behalf of Jason Roehm 
Sent: Monday, October 24, 2016 2:18:24 PM
To: boost@lists.boost.org
Subject: Re: [boost] Review Manager needed for stacktrace library


On 10/24/2016 02:05 PM, Antony Polukhin wrote:
>> I do love the idea of a portable facility to capture and/or display stack
>> traces at any desired point in a running program. Seems way overdue...
>>
>> It would be even more valuable if line number and source file information
>> were available. I recognize that you just can't get that under all
>> circumstances -- but maybe you could document the per-platform
>> circumstances in which that *could* be retrieved?
> The idea is good and I'm definitely going to experiment with that for
> Windows platform and for the Linux platforms soon. But I'm afraid that
> it may lead to bigger backtraces that do not fit onto screen and are
> harder to read.
>> I suggest an object with accessors returning those things, rather than a
>> struct, so no source code will come to rely on the size or specific data
>> layout of the returned entry. That should hopefully permit extension, if
>> there were ever still *more* information available. (In the Glorious
>> Future, perhaps we could retrieve function parameter values or something.)
>>
>> Each entry should support streaming to ostream to get reasonable formatting
>> in the presence or absence of source file and line number information. The
>> overall stacktrace ostream operator would rely on the entry ostream
>> operator.
> I've tried to walk that way. Unfortunately outputs differ a lot
> depending on the backtrace backend. For example instruction address
> may be reprsented as:
> * absolute address for currently loaded executable
> * offset from the stack frame
> * offset from the section in the binary
>
> It's hard to unify even those. More problems will arise with source
> files and line numbers. May be you'd like a different solution? What
> for are you willing to have such precise control?
I'll just chime in and agree with all of Nat's suggestions. stacktrace
would be an excellent addition to the standard library and I can think
of a lot of times in the past where I wished I had it on the shelf
already. I do agree though that file/line information is critical
(although I appreciate that it's not always available). I think it would
definitely be worth your time to add that functionality, even if it's
only on some platforms (like Linux).

Jason

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost