Hi, > One of my applications crashed in _ULx86_64_tdep_trace on line 504 here [...] > > Fix 1 pessimizes fast trace for every signal -- probably very undesirable > for a profiler, so Lassi would not like it. > > Fix 2 pessimizes fast trace only when sigaltstack is far enough away. > Undesirable for profiler with sigaltstack (which covers many Google apps). > > I don't see any major disadvantages for fix 3.
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. Off the top of my head I don't recall if that's possible on x86_64 systems in use, and what the dwarf info looks like for the kernel trampoline, but in principle I think fix 3 is a reasonable trade-off. > Tested on Linux/x86_64 (Ubuntu 10.04). No new failures. > > Comments? I'm ok with the patch, but will try to check if my concerns matter at all. I think there's currently just one layout in use for the signal trampoline - and if there's more than one I am not sure we're ok to cache the delta in fast trace anyway, so fix 3 may be just as good a choice in the end. In any case, I won't have time to look at this before mid next week or so, and it's fine with me to include the patch into libunwind now. Regards, Lassi _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
