Re: [boost] Review Manager needed for stacktrace library

Subject: Re: [boost] Review Manager needed for stacktrace library
From: Antony Polukhin (antoshkka_at_[hidden])
Date: 2016-10-24 14:05:51

2016-10-24 4:09 GMT+03:00 Nat Goodspeed <nat_at_[hidden]>:
> On Fri, Oct 14, 2016 at 2:22 AM, Antony Polukhin <antoshkka_at_[hidden]>
> wrote:
<...>
>> Library: https://github.com/apolukhin/stacktrace
>> Docs: http://apolukhin.github.io/stacktrace/index.html
>>
>> Anyone wishing to become the Review Manager for the library?
>
> Maybe? I already have a couple requests.

Thank you! But Niall already agreed to be the Review Manager:
http://www.boost.org/community/review_schedule.html

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

> If function name, source file and line number were (conditionally)
> available, I'd like to be able to retrieve an individual entry that has
> accessors returning each of those things -- instead of operator[] returning
> only a std::string for function name. Perhaps the source file and line
> number would have to be wrapped in boost::optional.

I'm writing stacktrace library as a prototype for further adoption
into the C++ Standard (I've got big ambitions and groundless
optimism). Additional dependency to std::optional could make the
adoption harder.

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

> And finally, I'd like both begin()/end() and rbegin()/rend(). size() and
> operator[] are great, but they don't support range for.

Sounds right. I'll add iterators and begin,end,rbegin,rend. Great thanks!

-- 
Best regards,
Antony Polukhin