Re: [boost] Review Manager needed for stacktrace library

Subject: Re: [boost] Review Manager needed for stacktrace library
From: Nat Goodspeed (nat_at_[hidden])
Date: 2016-10-24 14:49:59

On Mon, Oct 24, 2016 at 2:05 PM, Antony Polukhin <antoshkka_at_[hidden]> wrote:

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

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

Hence the desire to be able to retrieve individual components of a
stacktrace entry. A consumer could extract just the parts s/he cares
about. I do want operator<<(std::ostream&, const stacktrace_entry&) to
provide default formatting, but being able to extract individual
fields (without parsing your output!) would allow a consumer to format
in whatever way s/he needs.

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

Okay, that would be a reason to avoid std::optional. You could define
a distinguished value to mean "not available."

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

Well, to be honest, I doubt I care much about the instruction address
per se -- only the line number in the source file that it indicates.

But the wrapper layer for each backend could "do the right thing" in
extracting the instruction in whatever common form you decide, could
it not?

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

As I said, I want to be able to extract particular pieces of
information without having to maintain backend-specific parsing of the
string you emit.

Ultimately, of course, it's all for human consumption, but you can't
know the format I will consider ideal.

It's great to be able to extract a single stacktrace entry, and it's
good to have a "good enough" default formatting, but I'm just telling
you what I would like even better.  ;-)