I don't really have any substantial grounds to nack the change.
>From what I recall, this code path was mainly used to unwind through glibc
frames that don't (didn't?) have unwind info. IIRC virtually every stack
had one or two such frames at the end of the trace ("top-most frame", or
"start" of the stack, at least for the main thread).
I vaguely recall there were also common enough anomalies - mostly unwinds
starting off with bad unwind info, e.g. from an async signal, reading stack
wrong and going into random junk - that would cause stuck infinite traces
with zero-size frames, with unwinder making no progress. I'm not entirely
sure if it's possible to fully define "progress", but at least one of RIP
or RSP/CFA should be changing? Zero size frame (no CFA movement) where the
next unw_step will end up using the same RIP would be bad news, as would be
a short cycle of RIP addresses with no CFA change.
Other than that, my only concern would be whether the fast trace needs to,
or can be, taught to deal with such frames. As long as they don't happen in
anything performance sensitive, it wouldn't matter - the fast trace would
fall on the slow one, and everybody would be fine.
I'm not currently actively involved with the unwinding related stuff, and
am not able to brush up on the details right now - and could easily be
wrong. So please go ahead if it looks ok to you, maybe as long as we
protect against zero progress frames? Also, I don't have any recent data on
how likely missing / bad unwind data is these days for the general
(non-jit) case.
On Tue, May 13, 2014 at 8:27 AM, Arun Sharma <[email protected]> wrote:
> On Mon, May 12, 2014 at 4:03 PM, Kevin Modzelewski <[email protected]>
> wrote:
> > Hi, here's the original email:
> >
> http://lists.nongnu.org/archive/html/libunwind-devel/2014-04/msg00000.html
> >
>
> Thanks. Somehow this one email didn't make it into my inbox. Strange.
>
> > This "rsp=rbp" situation can occur if you have a small function, which
> > requires no stack-saved variables, that calls some other function that
> then
> > unwinds. Here's a contrived example:
>
> This extra constraint came from commit 9e98f15e and looks safe to
> relax as far as I can see. We hit this code path only when dwarf info
> is missing/invalid. So the condition is hard to reproduce by modifying
> tests/Ltest-bt.c for eg because compiler always generates valid unwind
> info for me :)
>
> I'll go ahead and apply the patch as long as Lassi (hope I got his
> email id right) doesn't Nack it.
>
> -Arun
>
_______________________________________________
Libunwind-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/libunwind-devel
