Re: [Libunwind-devel] [RFC][patch] Fix crash in _ULx86_64_tdep_trace when sigaltstack is too far away

[Lassi Tuura]

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