Hey, >> Hum... In principle I agree. I do have the concern about 3 that the layout >> (and dwarf info) change depending on registers in use, specifically things >> like whether process is saving expensive (AVX etc.) registers or not. > > I am not sure I understand. > > The sigcontext_addr points to 'ucontext_t', and in the patch we fetch > the register state from there. Surely you are not suggesting that ucontext_t > layout changes depending on AVX use?
No, I was just being paranoid... I submitted the bits to use kernel-provided dwarf info for signal frames on x86_64, instead of the previous heuristic signal frame detector/unwinder. The previous one caused problems, but I did not remember off the top of my head what it was about the dwarf-based signal unwinder that was better. Now that I thought it over, it's clear the current fast trace wouldn't work either if what I wrote is true: it freezes the stack deltas on first hit to the signal frame. I reviewed a few versions of linux kernel signal code, and it seems it always allocates a fixed amount of space, so indeed it seems safe assumption for now. For reference some of the past x86_64 discussions related to this: http://thread.gmane.org/gmane.comp.lib.unwind.devel/634 http://thread.gmane.org/gmane.comp.lib.unwind.devel/636 http://thread.gmane.org/gmane.comp.lib.unwind.devel/637 http://thread.gmane.org/gmane.comp.lib.unwind.devel/639 And: http://thread.gmane.org/gmane.comp.lib.unwind.devel/574 http://thread.gmane.org/gmane.comp.lib.unwind.devel/582 You might be interested in some of those related to the x86 version of the fast trace in the other thread. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
