[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libunwind-devel] Upstream unw_backtrace_skip?
From: |
Dave Watson |
Subject: |
Re: [Libunwind-devel] Upstream unw_backtrace_skip? |
Date: |
Mon, 30 Jan 2017 10:18:15 -0800 |
User-agent: |
Mutt/1.6.0 (2016-04-01) |
On 01/30/17 10:23 AM, Milian Wolff wrote:
> On Sunday, January 29, 2017 8:59:03 PM CET Bert Wesarg wrote:
> > Hi Milian,
> >
> > On Sat, Jan 28, 2017 at 10:20 PM, Milian Wolff <address@hidden> wrote:
> > > Hey all,
> > >
> > > now that libunwind is becoming more alive again, could we get the
> > > unw_backtrace_skip functionality upstream? For those who are unacquainted
> > > with it:
> > >
> > > It gives you the behavior of unw_backtrace, but skips the first N frames,
> > > see e.g.:
> > >
> > > https://gist.github.com/mikesart/8365549
> > >
> > > This is often required in profilers to skip frames introduced by the
> > > profiler itself.
> >
> > I don't see the what this adds as a feature, what cant already be done
> > by the caller after calling unw_backtrace itself? As ignoring the
> > first 'n' entries in the resulting backtrace buffer has the same
> > effect and it wont get faster.
>
> This is not about it being faster, it is just that in my opinion it is a
> common way to use this API. I.e. to get a backtrace N frames deep, I
> currently
> have to preallocate a buffer of N + M frame pointers and call unw_backtrace,
> then skip the M first pointers that go into "my" code. Vogl is doing the
> same,
> and I bet other users of libunwind will do so too.
>
> So this is really more about convenience, and the minor improvement that I
> don't need to allocate a buffer of N + M.
I can see the usefulness, but I'd lean towards not making the API
bigger for it since it is pretty trivial to add on top of the existing
API. Possibly a good candidate for an API breaking release like a 2.0
though?
> > What would be a enhancement for the
> > user, would be an option to skip everything till the first (or last)
> > entered signal frame on the stack. As that includes only the part
> > which triggered the signal, but not the signal handler.
>
> Note that in my case at least, I'm not triggering libunwind from a signal
> handler.
>
> > BTW, why is 'unw_backtrace' the only symbol without the usual '_U'
> > prefix, it is the only one with the 'unw_' prefix.
>
> No clue, I was wondering the same.
Yea I can't tell if there was a reason or just an oversight. I think
changing it now would be ABI breaking, unfortunately.