On 20 April 2010 18:52, Lassi Tuura <[email protected]> wrote: > Hi, > > I forgot to mention two things about this patch set: > > 1. The new signal frame detection code has a potential issue. The dwarf frame > information is only available after calling unw_step(), so if you chance to > set things up so you start unwinding at the kernel signal return frame, it > will get confused. I don't know how to fix this without major change how > unw_init_* work relative to unw_is_signal_frame(). I don't think it's > significant, as chances of constructing such a stack frame are slim; I don't > think it's possible with local unwind at all, and I don't even know how to > create the situation with remote (ptrace) unwinding.
As in back-trace from the signal trampoline? Single-stepping a program in a signal-handler will eventually get it back to the signal trampoline. Since code trying to single-step out of a handler relies on correct back-traces, it also turns out it is significant (and users do notice if the back-trace is wrong and complain :-). > > 2. As previously discussed the changes are partially based on earlier work in > frysk. The final code isn't really the same - libunwind has changed, I did > many things differently, and code in frysk wasn't a complete solution in my > tests - but it was useful to look at the frysk version for ideas! Sorry I > forgot to add the credit in the original mail; if someone from frysk cares > they might want to ask to be added to copyright list. Mark Wielaard did the frysk work so perhaps a nod to him in the news or somewhere? _______________________________________________ Libunwind-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/libunwind-devel
