FYI both of us who've tried this patch are experiencing the issue on LLVM-jitted code, which is why there isn't dwarf information available. Maybe I'll start another thread about my so-far-unsuccessful attempts to use _U_dyn_register...
I'm pretty new to this unwinding stuff, but it seems like even in the case that rbp=rsp, the unwinder is still making defined progress, since the return pointer got pushed on the stack above rbp. ie even if rbp_of_current_frame = rsp_of_current_frame, then rsp_of_previous_frame = rbp_of_current_frame + 8, so rsp_of_previous_frame > rsp_of_current_frame and we shouldn't get stuck in a loop? On Tue, May 13, 2014 at 10:10 AM, Arun Sharma <[email protected]> wrote: > On Tue, May 13, 2014 at 8:35 AM, Lassi Tuura <[email protected]> wrote: > > > 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. > > Yeah, we have protection against such an infinite loop later on in the > function. This check would apply only to the first such bad frame > without unwind info. > > -Arun >
_______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
